引用：JackJiang 发表于 2019-05-06 17:40
是啊，反正电脑又不会爆炸

引用：IM、你好 发表于 2019-05-06 14:32
一开始就怀疑那个进程问题，但是不确定，还是大胆的试试有用

是啊，反正电脑又不会爆炸

引用：JackJiang 发表于 2019-05-06 11:25
嗯，这么规律的现象，只有实例重复这一种可能。。

一开始就怀疑那个进程问题，但是不确定，还是大胆的试试有用

引用：IM、你好 发表于 2019-05-06 11:24
这个问题已经找到了，还是三楼的那个RainbowChatMQServer有两个进程，杀死一个就好了，麻烦了！！

嗯，这么规律的现象，只有实例重复这一种可能。。

引用：JackJiang 发表于 2019-05-06 10:11
那只能动用最笨的办法了：
1）关闭所有服务端和客户端（服务端都关闭完成后，在rabbitMQ管理后台看看还 ...

这个问题已经找到了，还是三楼的那个RainbowChatMQServer有两个进程，杀死一个就好了，麻烦了！！

引用：IM、你好 发表于 2019-05-06 09:39
这个看起来也没什么问题啊？

那只能动用最笨的办法了：
1）关闭所有服务端和客户端（服务端都关闭完成后，在rabbitMQ管理后台看看还存不存在连接，如果存在，那就是另有服务端实例在跑）；
2）把所有端的Log都清空；
3）逐个开启3个服务端；
4）分别只开一个客户端（包括一个app端和一个web端）；
5）只发一条消息；
6）抓出手机端的Log、web浏览器端(浏览器控制台下的Log)、app服务端的log、web服务端的log、MQ服务端的Log。

把以上抓出来的log整理一下，贴出来分析分析。上面这个作法，目的就是的追踪你说的丢掉的那条消息到底去哪里了，能理解我意思吗？

引用：IM、你好 发表于 2019-05-05 17:28
已经将RainbowChatServer、RainbowChatMQServer、RainbowChat_Web升级到最新，但是还是存在app端给web端 ...

隔一条才收到一条，这一定是服务端的哪个实例多部署了一个，仔细排查，没有其它可能性。

排查方法很简单，你把你认为的所有服务端全关闭，再按照先开app的服务端，再开web服务端，最后再开mq服务端的顺序，通过rabbitMQ的管理控制台（不知道怎么打开的话就百度），看看每一个服务端打开时的消息走向（MQ消息列表里被消费的情况）。

这一定是个sb问题，记得仔细排查。查出来了，别忘记打脸。。

引用：JackJiang 发表于 2019-04-23 14:56
请按照我在2楼的帖子里的讨论方法，先关掉所有的服务端，然后再保证所有实例唯一性运行，之后你再测。简 ...

已经将RainbowChatServer、RainbowChatMQServer、RainbowChat_Web升级到最新，但是还是存在app端给web端发消息，隔一条丢失一条；
比如说用户A（app）给用户B（web）发送111、222、333、444、555、666、777、888、999 九条消息，
用户B只接收到111、333、555、777、999
数据库存有111、333、555、777、999

引用：IM、你好 发表于 2019-04-23 14:10
RainbowChatMQServer启动有两个进程，这是正常的吗？

请按照我在2楼的帖子里的讨论方法，先关掉所有的服务端，然后再保证所有实例唯一性运行，之后你再测。简单的事情，别搞复杂化

先解决你消息间隔才能收到的问题吧，仔细看这个帖子，就能解决：
《[已解决] 求教MobileIMSDK和MobileIMSDK-web互通时消息间隔一条才能实时收到》