环境信息
- 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，会对消费端产生什么影响？
治标不治本，说了是客户端订阅高并发的消息，你消费不过来。你调大以后，无非就是延长异常的时间而已。
设置为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端
你好，我也遇到了这个问题。现象一样，在重连的时候飞行窗口（32 len）满了，重连成功后发送订阅请求，然后超时（超时异常导致连接断开），因为我程序设置了断开自动重连了，所以陷入了死循环。
你这个日志基本就是：断开连接后，你重新连上，缓存中的消息马上发送，每条消息交互4次（qos2）。你客户端又发起订阅，就是因为大量的缓存消息还在在传输，导致你订阅请求超时。
这里指的大量缓存消息还在传输是指 broker->client 链路吗。对于订阅的请求的回复，是不会放在飞行窗口里面的吧？
对于这个超时我目前无法确定是 broker → client 链路时耗时过长，导致总体时间过长超时；还是说 client 接收到订阅请求回复后没及时处理（处理飞行窗口的消息）导致超时
盼回复