断开重连报:Timed out waiting for a response from the server (32000)

环境信息

  • EMQ X 版本:EMQ X Broker 4.2.10
  • 操作系统及版本:centos 7.0
  • 其他

问题描述

飞行窗口和离线窗口满了后,如果:setCleanSession(false),断开重连会报错:
Timed out waiting for a response from the server (32000)

配置文件及日志

你这个是qos设置全是2,而且队列都是挤压满了。就算你马上连上,马上网络处理不过来,导致超时。改成qos 0试试。但是最终是你消费能力跟不上产生的能力,可以借用企业版桥接到Kafka这样就可以解决客户端消费的问题。

目前正常情况下消费没有问题,飞行窗口一直是0,消息队列也是0,但是订阅断开重连后就会报Timed out waiting for a response from the server (32000)

重连前是否已经满了。

重连的时候飞行窗口,和消息队列满了,消息量比较大,这种情况怎么避免?目前已经有五个客户端订阅消费了?而且tcp的连接断开也是正常的情况,但是只是断开重连就会出现这个问题

qos 2 这个本身就影响性能。可以先订阅改成qos 0 看看。tcp断开后,现在的方式肯定还是因队列满了而丢失数据的。干脆直接clean session 设置为true。如果不想丢失数据,那可以换成桥接到Kafka,你通过从Kafka中获取消息。

桥接需要企业版本?

clean session为false 的情况下,也会存在订阅断开重连的时候,飞行窗口、消息队列都满了的情况,这样就会存在消息丢失。怎么可以保证消息不丢失呢?

你现在这种方式,本身队列就已经满了,消息肯定丢失了,平台端采用订阅其实跟用不用clean session 为true没啥区别了,反正都是丢数据。如果设备端用clean session 用false,一个设备的订阅的消息本身并发不大,采用才有意义。用企业版,桥接存到Kafka进行磁盘落地,就不会因为客户端消费能力不够导致断开,并发每秒也可以达到10W的级别,可以借鉴官网有测试相关的报告。

你这个日志基本就是:断开连接后,你重新连上,缓存中的消息马上发送,每条消息交互4次(qos2)。你客户端又发起订阅,就是因为大量的缓存消息还在在传输,导致你订阅请求超时。

如果我把飞行窗口提高到32000,会对消费端产生什么影响?


飞行窗口的最大值可以设置为多少?消息队列最大值可以设置为多少?
externalinternal 分别是含义?谢谢

治标不治本,说了是客户端订阅高并发的消息,你消费不过来。你调大以后,无非就是延长异常的时间而已。

设置为0,没有限制。要设置的最大值,就是integer类型定义的最大值。external 和internal就是内外之分而已,比如你调用1883端口就是external,11883端口就是internal,就是一个客户端会有一个进程,每个连上后分配最大内存不同而已。如果你这里的问题不是缓存不够的问题,而是你传输中消费不过来。你看一下你的服务端日志是不是报socket busy。

日志里没有socket busy错误。说明不是消费不过来,客户端断开连接后,消息还是会向这个已经断开连接的客户端发送,最终导致飞行窗口和消息队列都满了,有参数可以设置飞行窗口正在处理的数据个数吗?比如:飞行窗口最大值为32,我可以设置最大的同时在线处理各位是12个,是飞行窗口不会满

飞行窗口是针对每个客户端而言,这个没所谓的同时处理个数,都是有时序的,可以看一下定义:飞行窗口和消息队列 | EMQ Docs qos 2,是需要交互4次。你把qos改成0,这个可以提高性能。但是根本原因是消费能力低于生产能力。

你再监控一下,异常时间段CPU是不是很高。还有你的网络带宽是否有限。

如果还是不确定问题在哪里,1.trace 这个客户端id进行跟踪日志,2同时抓包看一下重连后发起订阅是否发送到broker端