[已回复] MobileIMSDK服务端 gson 换成fastjson 出现错误,如何定位问题?

服务端sdk  我把  Protocal.java 中 toGsonString方法实现,,,,,,Gson改成了alibaba的fastjson
即  return JSON.toJSONString(this);

导致qos机制异常如下图

        


请问下为何会出现这种错误?

用哪个JSON库无所谓，我平时都是Gson和fastjson混着用，随便。

而且你的图上的问题不是关于json的错误，json的解析正常的很。你的问题是否是B已收到消息，而A这边却报消息未送达是吗？

引用：JackJiang 发表于 2017-07-11 17:38
用哪个JSON库无所谓，我平时都是Gson和fastjson混着用，随便。

而且你的图上的问题不是关于json的错误， ...

感谢回复,B收到3条重复消息,而A却报消息未送达.我对测试代码只改了这个json转换,然后出现上图错误,,改回Gson就又正常了

引用：kelefun 发表于 2017-07-11 17:41
感谢回复,B收到3条重复消息,而A却报消息未送达.我对测试代码只改了这个json转换,然后出现上图错误,,改回G ...

看看客户端和服务端的Log，把Log贴的详细一点。
根据MobileIMSDK的算法，如果不是你自已点了重复按了几下按钮发送，接收端是不会重复显示的，不信你去看看源码，接收端本身就有去重能力。

引用：JackJiang 发表于 2017-07-11 18:00
看看客户端和服务端的Log，把Log贴的详细一点。
根据MobileIMSDK的算法，如果不是你自已点了重复按了 ...

服务端jdk 1.8
客户端为安卓模拟器 22和23版本
确认只点击了一次的
日志详情见附件,大概如下:
安卓客户端日志(打印时间模拟器时间没校对)
07-11 10:37:41.611 9999-10022/net.openmob.imdemo D/QoS4SendDaemon: 【IMCORE】【QoS】=========== 消息发送质量保证线程运行中, 当前需要处理的列表长度为1...
07-11 10:37:41.612 9999-10022/net.openmob.imdemo D/LocalUDPSocketProvider: 【IMCORE】isLocalUDPSocketReady()==true，直接返回本地socket引用哦。
07-11 10:37:41.613 9999-9999/net.openmob.imdemo D/QoS4SendDaemon: 【IMCORE】【QoS】指纹为c8041259-6b05-48fb-a189-9ba459b3d45b的消息包已成功进行重传，此次之后重传次数已达2(最多2次).
b.imdemo D/QoS4SendDaemon: 【IMCORE】【QoS】指纹为c8041259-6b05-48fb-a189-9ba459b3d45b的消息包重传次数已达2(最多2次)上限，将判定为丢包！
07-11 10:37:46.616 9999-9999/net.openmob.imdemo D/MessageQoSEventImpl: 【DEBUG_UI】收到系统的未实时送达事件通知，当前共有1个包QoS保证机制结束，判定为【无法实时送达】！


--------
服务端日志

[DEBUG] - [18:36:04.640]【DEBUG_回调通知】正在调用回调方法：OnVerifyUserCallBack...(extra=null) | (ServerEventListenerImpl^onVerifyUserCallBack:55)
[DEBUG] - [18:36:04.641]【@】当前在线用户共(2)人-------------------> | (OnlineProcessor^__printOnline:63)
[DEBUG] - [18:36:04.641]【IM_回调通知OnUserLoginAction_CallBack】用户：22 上线了！ | (ServerEventListenerImpl^onUserLoginAction_CallBack:73)
[DEBUG] - [18:36:06.527]【IMCORE-本机QoS】【QoS发送方】=========== 消息发送质量保证线程运行中, 当前需要处理的列表长度为2... | (QoS4SendDaemonRoot^doTaskOnece:56)
[DEBUG] - [18:36:06.527]【IMCORE-本机QoS】【QoS发送方】指纹为a9191c46-a16f-4ede-a4a9-bf516fc80acb的消息包已成功进行重传，此次之后重传次数已达1(最多1次). | (QoS4SendDaemonRoot^doTaskOnece:82)
[WARN] - [18:36:06.527]【IMCORE-本机QoS】【QoS发送方】指纹为0107eeee-c3d7-4a50-8319-4c441d34867a的包距"刚刚"发出才1886ms(<=2000ms将被认定是"刚刚"), 本次不需要重传哦. | (QoS4SendDaemonRoot^doTaskOnece:75)
[DEBUG] - [18:36:11.528]【IMCORE-本机QoS】【QoS发送方】=========== 消息发送质量保证线程运行中, 当前需要处理的列表长度为2... | (QoS4SendDaemonRoot^doTaskOnece:56)
[DEBUG] - [18:36:11.528]【IMCORE-本机QoS】【QoS发送方】指纹为a9191c46-a16f-4ede-a4a9-bf516fc80acb的消息包重传次数已达1(最多1次)上限，将判定为丢包！ | (QoS4SendDaemonRoot^doTaskOnece:67)
[WARN] - [18:36:11.528]【IMCORE-本机QoS】【QoS发送方】指纹为a9191c46-a16f-4ede-a4a9-bf516fc80acb的消息已成功从发送质量保证队列中移除(可能是收到接收方的应答也可能是达到了重传的次数上限)，重试次数=1 | (QoS4SendDaemonRoot^remove:178)
[DEBUG] - [18:36:11.528]【IMCORE-本机QoS】【QoS发送方】指纹为0107eeee-c3d7-4a50-8319-4c441d34867a的消息包已成功进行重传，此次之后重传次数已达1(最多1次). | (QoS4SendDaemonRoot^doTaskOnece:82)
[DEBUG] - [18:36:11.528]【DEBUG_QoS_S2C事件】收到系统的未实时送达事件通知，当前共有1个包QoS保证机制结束，判定为【无法实时送达】！ | (MessageQoSEventS2CListnerImpl^messagesLost:40)
[INFO] - [18:36:15.504][IMCORE]>> 收到客户端{uid:11}/172.16.150.30:64334的通用数据发送请求. | (ServerCoreHandler^messageReceived:118)
[DEBUG] - [18:36:15.505]【@】当前在线用户共(2)人-------------------> | (OnlineProcessor^__printOnline:63)
[DEBUG] - [18:36:15.506]【DEBUG_回调通知】[typeu=-1]收到了客户端11发给客户端22的消息：str=hello | (ServerEventListenerImpl^onTransBuffer_C2C_CallBack:129)
[DEBUG] - [18:36:16.527]【IMCORE-本机QoS】【QoS发送方】=========== 消息发送质量保证线程运行中, 当前需要处理的列表长度为1... | (QoS4SendDaemonRoot^doTaskOnece:56)
[DEBUG] - [18:36:16.527]【IMCORE-本机QoS】【QoS发送方】指纹为0107eeee-c3d7-4a50-8319-4c441d34867a的消息包重传次数已达1(最多1次)上限，将判定为丢包！ | (QoS4SendDaemonRoot^doTaskOnece:67)
[WARN] - [18:36:16.527]【IMCORE-本机QoS】【QoS发送方】指纹为0107eeee-c3d7-4a50-8319-4c441d34867a的消息已成功从发送质量保证队列中移除(可能是收到接收方的应答也可能是达到了重传的次数上限)，重试次数=1 | (QoS4SendDaemonRoot^remove:178)
[DEBUG] - [18:36:16.527]【DEBUG_QoS_S2C事件】收到系统的未实时送达事件通知，当前共有1个包QoS保证机制结束，判定为【无法实时送达】！ | (MessageQoSEventS2CListnerImpl^messagesLost:40)
[INFO] - [18:36:21.557][IMCORE]>> 收到客户端{uid:11}/172.16.150.30:64334的通用数据发送请求. | (ServerCoreHandler^messageReceived:118)
[DEBUG] - [18:36:21.557]【@】当前在线用户共(2)人-------------------> | (OnlineProcessor^__printOnline:63)
[DEBUG] - [18:36:21.558]【DEBUG_回调通知】[typeu=-1]收到了客户端11发给客户端22的消息：str=hello | (ServerEventListenerImpl^onTransBuffer_C2C_CallBack:129)
[INFO] - [18:36:26.561][IMCORE]>> 收到客户端{uid:11}/172.16.150.30:64334的通用数据发送请求. | (ServerCoreHandler^messageReceived:118)
[DEBUG] - [18:36:26.561]【@】当前在线用户共(2)人-------------------> | (OnlineProcessor^__printOnline:63)
[DEBUG] - [18:36:26.562]【DEBUG_回调通知】[typeu=-1]收到了客户端11发给客户端22的消息：str=hello | (ServerEventListenerImpl^onTransBuffer_C2C_CallBack:129)

引用：不信你去看看源码，接收端本身就有去重能力

今天才下载的demo研究,还没仔细看源码.关键是我服务端只改了一个方法json转换,改回gson就正常,
按道理来讲fastjson跟gson转化的结果都是一样的,不应该有区别呀

引用：kelefun 发表于 2017-07-11 18:45
今天才下载的demo研究,还没仔细看源码.关键是我服务端只改了一个方法json转换,改回gson就正常,
按道理来 ...

客户端的日志显示没有收到对方的应答包，理论上双方跟服务端的双向通信正常时是不会存在这种情况的。

另外，强烈建议不要用安桌模拟器，这玩意要多垃圾有多垃圾，会出现一些莫名其妙的问题，尽量找真机测试，模拟器上出的任何问题都不值得关注。

遇到问题要讲方法，既然怀疑是json库的差异，那就把这段toJsonString的字串结果分别用2个库打印出来，对比看看差异在哪就明白了，如果打印的结果完全一样，那就再找其它问题。找不到确切问题，那就用这排除法。

引用：JackJiang 发表于 2017-07-11 21:01
客户端的日志显示没有收到对方的应答包，理论上双方跟服务端的双向通信正常时是不会存在这种情况的。

...

打印2个库的转换结果,当时就试过了,结果就是字段排序不一样.其他没啥区别.

我有时间再找找原因吧,再次感谢解答