实战疑问以及讨论
环境
- EMQX 版本：4.4.3
- 操作系统版本：centos
- ExHook: for-emqx-v43 Java
背景
部门服务偶尔出现问题跟上面三个链接的情况差不多一致（Timed out waiting for a response from the server (32000)）
我这边的服务情况：消息量不大，QOS1, sub 端进行重连（可能是网络原因），然后消息窗口有积累一些消息，存在队列满的情况，同时sub端重连后（同一个 session）重新发起 topic 订阅，出现超时异常，然后断开又继续重连，一直循环下去，没法订阅主题的同时也没法消费飞行窗口的消息。
上面的疑问是client 心跳和主题订阅的响应不是放在飞行窗口的吧，没排查出为什么会产生超时的情况。
采取的解决方案
针对上诉所描述的问题，部门暂时没法解决，决定采用 exhook 的方式对消息进行 mq 转发，放弃 pub/sub 的方式。
exhook server 的更新困难点
由于设备一直往 broker 发送消息，部门的痛点是如何在 exhook server 更新的时候，防止消息丢失（尽最大努力防止丢失）。按照官方的说法 exhook 是没推送重试的，如果按照正常的关掉|更新，势必会产生消息丢失
目前能想到的一些方案
第一种
需要更新的 exhook server 版本部署上去，旧版本的 exhook server 不kill，同时把 nginx 转发的域名地址映射改为新版本的 exhook server。
等待 旧版本的 grpc client 重连的时候，连接到新版本的 exhook server
但是这样存在很大的不确定性，client 什么时候才能全部连接到新版本上面去，人工好像没法干预。重启插件应该也会产生消息丢失吧。
第二种
启动 sub/pub 模式，订阅和 exhook server 一样的事件主题转发到 mq，一旦 kill 掉exhook server 后，消息就会被 sub/pub 承接过去，等到 exhook server 更新上线后，重新接管消息。再把 sub/pub 模式下线
ps：需要在exhook messagepublished 对消息进行拦截不发布