我有许多QoS2级别的消息,这些消息在MQTT代理或客户端出现问题时导致问题.这些问题可能包括
通常,当MQTT客户端开始从代理接收超时或其他错误时,消息将存储在持久性存储中(正在进行的消息),并最终将重新发布.
但是,如果Paho客户端失去与代理的连接,则不会再在飞行中考虑消息,Paho也不会存储消息.此时,似乎应用程序负责持久保存这些消息(在paho之外)并重新发布它们.
我是否正确地说,当MQTT代理变得不可用时,Paho MQTT客户端无法帮助我保证这些QoS2级别的消息将被重新传递?
那么我如何区分以下情况,其中client.publish导致了一个MqttException,其中Paho没有持久化消息.
Client is currently disconnecting (32102)
at org.eclipse.paho.client.mqttv3.internal.ClientComms.shutdownConnection(ClientComms.java:297)
at org.eclipse.paho.client.mqttv3.internal.CommsSender.handleRunException(CommsSender.java:154)
at org.eclipse.paho.client.mqttv3.internal.CommsSender.run(CommsSender.java:131)
at java.lang.Thread.run(Thread.java:745)
Run Code Online (Sandbox Code Playgroud)
以下它确实持续存在
Timed out waiting for a response from the server (32000)
at org.eclipse.paho.client.mqttv3.internal.Token.waitForCompletion(Token.java:94)
at org.eclipse.paho.client.mqttv3.MqttToken.waitForCompletion(MqttToken.java:50)
at org.eclipse.paho.client.mqttv3.MqttClient.publish(MqttClient.java:315)
at org.eclipse.paho.client.mqttv3.MqttClient.publish(MqttClient.java:307)
Run Code Online (Sandbox Code Playgroud)
显然,我也可以开始记账并单独保留所有失败的消息,但随后我可能最终得到QoS等级2重复(由Paho和我自己重新发布的消息).
如何对客户进行编程?
以下是Paho的一些例外和持久性行为
Paho的一些最佳实践是什么?
小智 6
我没有设计Java客户端,但我可以看到这种行为是如何产生的,并且它可能令人困惑.我假设我们在这里谈论同步客户端?并且在调用发布时会遇到所有这些异常?
主要原则是:
但这两种情况都被报告为例外,这是无益的.
在C客户端,我遵循以下规则:
所以你知道如果你收到错误,你必须重试发布调用.
对于Java客户端,我们可以通过以下方式改善情况:
要么
创建另一类异常,清楚地显示消息何时存在并且不存在,例如
请注意,我们计划在6月份发布1.2版本的"离线缓冲",这意味着当客户端未连接时,该消息可以保留.