引用:JackJiang 发表于 2018-06-08 19:59 好的,谢谢老大。 |
引用:师傅不见了 发表于 2018-06-08 18:12 你看看这是我模拟你同样的错误码的服务端log,不会出现你那个异常: 所以你这个异常,真是费解。你可以用源码跟踪一下,看看为何会在你的环境下出现这个异常。但实际上这个异常不影响什么,因为你客户端的会话已经被关闭了,服务端的这些代码只是在清理这个会话所占用的资源,而实际上这个会话还没占用什么资源。 另外,我刚抽了2个小时时间,按照你报告的这个问题作了更健壮的代码优化,你可以下载最新版MobileIMSDK v3.3,你的环境下应该不会再报这个问题了,你试试看。 |
引用:JackJiang 发表于 2018-06-08 14:52 重新下载了之后,一行代码不改直接运行 客户端和server 都是ok的 然后修改server 端 onVerifyUserCallBack 返回值 之后重新运行 还是报一样的错误,客户端同样能收到错误码 会不会是QOS 线程 没有判断用户登录失败? |
引用:师傅不见了 发表于 2018-06-08 14:49 JDK1.8不会有什么问题。 我建议你这样来排查: 1)把客户端demo和服务端demo一行代码一改,原样运行,看看在你这环境下能不能正常; 2)如果第1)步正常,则其它任何代码也别改,只把错误码改成10再来看看结果(这一次要注意一下客户端的log ,另外建议下次贴Log时把日志贴的全一点,不只是异常的那段。) 你重新下载最新版,不要用你现在的代码,就怕你不小心改过了但已记不起是否改过。 |
按你设置的错误码,我专门帮你验证了一遍,没有任何问题(看我的第2张图里,表示已经正常拿到了服务端返回的码): 顺便问一句,你的客户端和服务端分别运行在什么版本的JDK上的? |
引用:师傅不见了 发表于 2018-06-08 11:04 你的MobileIMSDK版本是多少? |
引用:师傅不见了 发表于 2018-06-07 22:58 那肯定是另有原因,我怀疑你用的代码有不合理的地方。 你这样做: 1)把你自已加的或改的客户端端代码,贴出来,主要是跟demo相比,不同的地方; 2)参照1),同样把加的或动过的代码贴出来。 我帮你分析 分析 。用了这久,你的问题第一次看见,肯定有奇怪的地方。 |
引用:JackJiang 发表于 2018-06-07 22:02 MINA 版也报同样的异常 [DEBUG] - [22:49:40.588]【IMCORE-本机QoS】【QoS发送方】=========== 消息发送质量保证线程已成功启动 | (QoS4SendDaemonRoot^startup:292) [INFO] - [22:49:40.592][IMCORE] 配置项:未开启与MobileIMSDK Web的互通. | (ServerLauncher^startup:223) [INFO] - [22:49:40.704][IMCORE] 基于MobileIMSDK的UDP服务正在端口7901上监听中... | (ServerLauncher^startup:232) [INFO] - [22:51:20.117][IMCORE]与{uid:null}/127.0.0.1:52874的会话建立(sessionCreated)了... | (ServerCoreHandler^sessionCreated:374) [INFO] - [22:51:20.123][IMCORE]与{uid:null}/127.0.0.1:52874的会话(sessionOpened)打开了... | (ServerCoreHandler^sessionOpened:387) [INFO] - [22:51:20.171][IMCORE]>> 客户端{uid:null}/127.0.0.1:52874发过来的登陆信息内容是:loginInfo=1|getToken=aaa | (LogicProcessor^processLogin:206) [DEBUG] - [22:51:20.172]【DEBUG_回调通知】正在调用回调方法:OnVerifyUserCallBack...(extra=null) | (ServerEventListenerImpl^onVerifyUserCallBack:55) [DEBUG] - [22:51:20.591]【IMCORE-本机QoS】【QoS发送方】=========== 消息发送质量保证线程运行中, 当前需要处理的列表长度为1... | (QoS4SendDaemonRoot^doTaskOnece:148) [WARN] - [22:51:20.592]【IMCORE-本机QoS】【QoS发送方】指纹为9639182f-3cbb-4c18-83e2-db0c37ffabbd的包距"刚刚"发出才401ms(<=2000ms将被认定是"刚刚"), 本次不需要重传哦. | (QoS4SendDaemonRoot^doTaskOnece:187) [DEBUG] - [22:51:25.591]【IMCORE-本机QoS】【QoS发送方】=========== 消息发送质量保证线程运行中, 当前需要处理的列表长度为1... | (QoS4SendDaemonRoot^doTaskOnece:148) [INFO] - [22:51:25.592][IMCORE]toSession==null >> id=0的用户尝试发给客户端-1的消息:str={"code":2000}因接收方的id已不在线,此次实时发送没有继续(此消息应考虑作离线处理哦). | (LocalSendHelper^sendData:182) [WARN] - [22:51:25.592]【IMCORE-本机QoS】【QoS发送方】指纹为9639182f-3cbb-4c18-83e2-db0c37ffabbd的消息包重传失败,它的重传次数之前已累计为1(最多1次). | (QoS4SendDaemonRoot^doTaskOnece:216) [ERROR] - [22:51:30.155][IMCORE]exceptionCaught捕获到错了,原因是:null | (ServerCoreHandler^exceptionCaught:153) java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) at net.openmob.mobileimsdk.server.processor.OnlineProcessor.getOnlineSession(OnlineProcessor.java:140) at net.openmob.mobileimsdk.server.ServerCoreHandler.sessionClosed(ServerCoreHandler.java:302) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.sessionClosed(DefaultIoFilterChain.java:797) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:504) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:48) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:927) at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:108) at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) [DEBUG] - [22:51:30.590]【IMCORE-本机QoS】【QoS发送方】=========== 消息发送质量保证线程运行中, 当前需要处理的列表长度为1... | (QoS4SendDaemonRoot^doTaskOnece:148) [DEBUG] - [22:51:30.591]【IMCORE-本机QoS】【QoS发送方】指纹为9639182f-3cbb-4c18-83e2-db0c37ffabbd的消息包重传次数已达1(最多1次)上限,将判定为丢包! | (QoS4SendDaemonRoot^doTaskOnece:169) [WARN] - [22:51:30.591]【IMCORE-本机QoS】【QoS发送方】指纹为9639182f-3cbb-4c18-83e2-db0c37ffabbd的消息已成功从发送质量保证队列中移除(可能是收到接收方的应答也可能是达到了重传的次数上限),重试次数=1 | (QoS4SendDaemonRoot^remove:393) [DEBUG] - [22:51:30.594]【DEBUG_QoS_S2C事件】收到系统的未实时送达事件通知,当前共有1个包QoS保证机制结束,判定为【无法实时送达】! | (MessageQoSEventS2CListnerImpl^messagesLost:40) [DEBUG] - [22:54:40.589]【IMCORE-本机QoS】【QoS接收方】++++++++++ START 暂存处理线程正在运行中,当前长度0. | (QoS4ReciveDaemonRoot^doTaskOnece:105) [DEBUG] - [22:54:40.591]【IMCORE-本机QoS】【QoS接收方】++++++++++ END 暂存处理线程正在运行中,当前长度0. | (QoS4ReciveDaemonRoot^doTaskOnece:142) |
引用:JackJiang 发表于 2018-06-07 22:02 好的我先试试 |
理论上你描述的问题不应该发生,而且这个异常基本不可能是你说的这种情况下发生的。 我建议你换成MINA版,用你同样的代码试试,看看MINA版什么效果,因为MINA版是久经考验的,可以用它来作参考基准,再来排查netty版的问题。 另外,建议你把Log贴的全面一点。 你按我说的来试试,然后有情况再贴出来,我会帮你看看 |