Inflight messages cleaning

[Flaer]

Hi mochi-co team. We start to research your broker realisation. Its fast and furious :) we impressed so much! But we find out that after enabling persistence inflight messages stores for infinit time and not clears at all if client never reconnects. Are we right? And if so, what is a proper way to clear it? Because store is growing unlimited. We assume to use ttl or some sort of size limitters. And another question: do you have a plans for managing such behaviour by adding some sort of logic inside the broker.

Best regards, Lenar.

[mochi-co]

Thanks @Flaer!

In theory this sounds correct.

An inflight message is created when a message is published to a subscriber using QOS > 0. The inflight message is then removed (either from memory and/or the store if one exists) when an ack response is received, or if not, the message is retained in memory until delivery can be confirmed. In theory this should only occur if the client drops before sending the ack, or some network disruption prevents the first packet from being delivered at the subscriber end, so the number of 'hanging' inflight messages should (in theory) be exceedingly rare.

There's another case in which inflight messages can build up, which is the because the MQTT 3.1.1 specification requires that messages with QOS > 0 must be queued to be delivered to offline clients when they reconnect (if the client is a persistent session, aka. cleanSession is set to false).

However, I believe we need to make some changes to properly accommodate this - as you noted - if the clients never reconnect, then the number of QOS packets for each offline client can build up substantially.

In my opinion the best (and probably simplest) solution would be to add a TTL for inflight messages, with a customisable default of say, 24 hours. I am going to think and investigate, and determine a workable solution.

[Flaer]

Great to hear it! For now we added ttl through redis configuration property because we use redis as persistence layer.

[mochi-co]

@Flaer I am currently looking into resolving this now, but I came back to this because I remember you mentioned you were using Redis as a persistence layer. We don't currently have Redis in the persistence folder, are you interested in PRing it (or a version of it) at all? :)

[mochi-co]

Fixed in v1.3.0 with new TTL/period resend support for inflight messages.