前提:客户端和服务端基于websocket进行交互,客户端每隔8s发送心跳,服务端检测心跳,超过三分钟没收到会关闭session。
现象:客户端日志记录发送了心跳消息,服务端没收到心跳,超时后服务端关闭sessionA,客户端新建了会话sessionB,过了会又收到了之前sessionA的消息,由于sessionA已经关闭,所以isOpen 方法返回 false。
最开始并没有关注到sessionA在关闭后收到的消息,所以一直以为是丢消息了,服务端说是客户端的问题,客户端说明明发送了消息,日志都记录了。
当然现有消息交互方式也是有问题的,客户端记录发送成功,并不表明真的成功了,所以靠谱的应该是加上业务层的ack,客户端收到服务端的业务ack才真正的是表明消息发送成功了。现在介绍为什么会出现上面的现象。
客户端跟服务端是单会话形式,所以被@OnMessage标注的方法会依次触发,什么意思?客户端A往服务端发送了1、2、3三个消息,服务端先处理1、处理完之后才会处理2,然后是3。当然了,session之间是并发的,互不影响,只是session内消息是一条一条执行。问题就在这,如果消息1执行很慢,时间超过3分钟,而心跳消息2、3...由于得不到处理就会触发超时关闭session。
结论:消息并没有丢,而是由于消息处理时间太久,导致后续消息得不到执行,程序判断心跳超时 关闭了session。原因找到了,怎么处理就比较容易了。