Feature Request: offer control over message buffering when disconnected

[fraschbi]

Problem or use case

MQTT messages that are sent via the HiveMQ client library (here, reactive API via Mqtt5RxClient.publish(Flowable), Android) are buffered if the client is not connected to a broker and sent later at connection re-establishment. This is independent of the QoS and TTL of the message, and also happens when the time until connection re-establishment is long (e.g. 10 minutes), as long as session does not expire until the client can reconnect. Moreover, there seems to be a short time frame (a couple of seconds on our Android devices) where Mqtt5RxClient.state.isConnected=true but the Mqtt5RxClient buffers the message, probably because it already detected connection loss.

This leads to unwanted behaviour on our side, e.g. delayed sending of messages after reconnect which we would like to discard, as the sent information is not useful anymore (e.g. realtime position data) and overwhelms the server with outdated messages in very short succession. Workaround possibilities are limited as Mqtt5RxClient.state.isConnected=true does not always indicate if messages would be buffered.

Preferred solution or suggestions

We would like to have more control over the buffering mechanism. In particular:

• possibility to disable buffering (completely / for particular QoS levels) - or maybe (more general) configure buffer sizes

• possibility to take into account the remaining TTL (i.e., for the delayed sending after connection-re-establishment the TTL is reduced by the time that elapsed since the message was passed to Mqtt5RxClient; if the TTL becomes 0 or less, the message is discarded)

[SgtSilvio]

I labeled this issue as a feature as this was already planned for a future version, but it is currently not specified enough to be implemented. We will probably release a new major version (2.0.0) in a few month, where this is likely to be included.

[gwimmel]

Sounds good. Would any feedback be helpful to make the specification more concrete (in addition to the above description)?

[kaiseiyouse]

I noticed there is a republishIfSessionExpired option to control whether message buffering is desired during disconnected state. But the problem is that it doesn't give user finer control over how each message will be buffered. Providing such options in the publish method would be really helpful.

possible configure options:

• disable buffering for certain QOS levels (for exmaple qos 0 publishes)
• buffer size
• replacement policy (FIFO, TTL based, etc)

explicit control of internal publishing queue

• manually drain/clear the queue
• overwrite queue entry (realtime data becomes stale)