多次调用UserIdSettingKit.settingUserId，会出现逻辑服请求网关服超时的情况

[dx1ngy]

你的问题

作者你好，使用单机多进程方式分别启动网关服、对外服、逻辑服，使用模拟客户端调用1-0路由，action方法中为UserIdSettingKit.settingUserId，第一次调用没问题正常返回，再次调用这个路由则会出现逻辑服请求网关服超时的情况
com.iohao.game.bolt.broker.client.kit.UserIdSettingKit.settingUserId:99 - Rpc invocation timeout[responseCommand TIMEOUT]! the address is 127.0.0.1:10200

复现步骤

game.zip

版本

• ioGame version:

dev分支最新代码

[iohao]

同一个连接只能调用一次登录。

[dx1ngy]

同一个连接只能调用一次登录。

为啥回报超时错误呢？感觉直接返回false是不是会好一点，这块是怎么考虑设计的？

[iohao]

正常业务不会登录两次。

方法内返回的 false，里面会打印错误日志。

[dx1ngy]

正常业务不会登录两次。

方法内返回的 false，里面会打印错误日志。

我大概跟了一下，因为登录完之后channelId为null，请求到逻辑服之后报错没返回导致超时，之后我又找到下面的判断

为什么登录之后不传channelId，传了会有什么问题么，可不可以解答一下。

[iohao]

登录后，该 channelId 就没有意义了。

see

ioGame/common/common-core/src/main/java/com/iohao/game/action/skeleton/protocol/HeadMetadata.java

Lines 119 to 129 in ba88679

	/**
	* netty 的 channelId。
	* <pre>
	* 框架存放 netty 的 channelId 是为了能在对外服查找到对应的连接。
	* 当玩家登录后，框架将会使用玩家的 userId 来查找对应的连接（channel），而不是 channelId ；
	* 因为 channelId 的字符串太长了，每次将该值传输到逻辑服会小小的影响性能。
	*
	* 当玩家登录后，框架将不会使用该属性了；开发者如果有需要，可以把这个字段利用起来。
	* </pre>
	*/
	String channelId;

[dx1ngy]

登录后，该 channelId 就没有意义了。

see

ioGame/common/common-core/src/main/java/com/iohao/game/action/skeleton/protocol/HeadMetadata.java

Lines 119 to 129 in ba88679

	/**
	* netty 的 channelId。
	* <pre>
	* 框架存放 netty 的 channelId 是为了能在对外服查找到对应的连接。
	* 当玩家登录后，框架将会使用玩家的 userId 来查找对应的连接（channel），而不是 channelId ；
	* 因为 channelId 的字符串太长了，每次将该值传输到逻辑服会小小的影响性能。
	*
	* 当玩家登录后，框架将不会使用该属性了；开发者如果有需要，可以把这个字段利用起来。
	* </pre>
	*/
	String channelId;

channelId这个地方我明白了。还有一个我纠结的点在于SettingUserIdMessage这个消息对外服接收到之后，可以判断是否登录了，如果登录了就返回false，而不是现在这样因为channelId为null，导致超时不返回消息，逻辑服再捕获异常返false，感觉怪怪的。

[iohao]

同一个用户允许多次登录才是问题，建议在 action 中自己加个用户是否已经登录了的判断。

ba88679

[shuaiyinoo]

本来我也遇到过这个问题但是规避了
从之前的 17 版本登录的时候就存在
后面就没有去管了 多少有点缺陷 登录之前先判断是否存在再顶号
我看作者在最新的版本已经修复了 很开心 #334
等我更新一波 看看是不是真的修复了 之前退出登录会报错导致登录不上或者再次登录需要 3-5 秒才能成功

[shuaiyinoo]

感谢由于断线重连一直很慢 看到这个 BUG 修复现在都是秒重新连接上 太开心了

[iohao]

使用技巧： 自定义注解配合 ioGame 线程相关 (yuque.com) 的线程编排，可以实现让登录方法交给虚拟线程处理，这样就不会阻塞用户线程。

1，在 loginVerify 方法上添加一个自定义的 VirtualThread 注解。

加上 VirtualThread 注解后，action 方法就能保持同样的编码风格，不需要显示的将代切换到其他线程中执行了。

@ActionController(LoginCmd.cmd)
public class LoginAction {
    /**
     * 登录验证
     *
     * @param loginVerify 登录
     * @param flowContext flowContext
     * @return 用户信息
     */
    @VirtualThread
    @ActionMethod(LoginCmd.loginVerify)
    public UserInfo loginVerify(LoginVerify loginVerify, FlowContext flowContext) {
        ... ... 省略部分代码
    }
}

2，重写 RequestMessageClientProcessorHook 接口，处理 VirtualThread 注解。

public final class MyRequestMessageClientProcessorHook implements RequestMessageClientProcessorHook {

    @Override
    public void processLogic(BarSkeleton barSkeleton, FlowContext flowContext) {
        ActionCommand actionCommand = flowContext.getActionCommand();
        var annotation = actionCommand.getAnnotation(VirtualThread.class);
        // 使用虚拟线程处理业务
        if (Objects.nonNull(annotation)) {
            TaskKit.executeVirtual(() -> barSkeleton.handle(flowContext));
            return;
        }

        ... ...
    }
}

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface VirtualThread {
}