记一次MQTT偶现无法发送Message至Android客户端的解决

Bug概述

  • 服务端、客户端通信使用MQTT
  • 客户端发生 小概率偶现 无法收到服务端Message,而后端显示已发送

Bug排查结果

  • 客户端的MqttAndroidClient使用的ClientId因后端 没给值,导致ClientId为空 — 让后端解决
  • 客户端没有断线重连机制,不要听信部分地方说的 在MqttCallbackExtended的connectionLost方法中写connect方法,这是错误的,有更好的,用MqttConnectOptions的setAutomaticReconnect方法 — 客户端解决
  • Android客户端的MqttAndroidClient 执行connect存在,无法释放的情况,具体是Service的onDestory中写了disconnect,在onStartCommand中写了connect,这不对称,改至onCreate — 客户端解决
  • 解决上一条,正因为有上一条,结合MqttConnectOptions的setCleanSession方法的描述(见下面的说明),将setCleanSession设置为true解决 — 客户端解决
    /**
    • Sets whether the client and server should remember state across restarts and reconnects.


      • If set to false both the client and server will maintain state across

      • restarts of the client, the server and the connection. As state is maintained:


        • Message delivery will be reliable meeting

        • the specified QOS even if the client, server or connection are restarted.

        • The server will treat a subscription as durable.


      • If set to true the client and server will not maintain state across

      • restarts of the client, the server or the connection. This means


        • Message delivery to the specified QOS cannot be maintained if the

        • client, server or connection are restarted

        • The server will treat a subscription as non-durable


        */

        状态会被保留,常驻。若会连接泄露,则会导致服务端有同一个topic多份的监听实例,
        注意。。。。这里我猜测的。。。我觉得后端的mqtt部分,对多份监听只回调了第一份。而我们新的监听实例在后面。。。故,这就接受不到回调。自然就出现了后端有发送,客户端没有接收到的结果。

你可能感兴趣的:([工作记录])