Home » Devtech review » LangsNTechs » Java » Eclipse Paho » Paho MQTT client, max in-flight messages for QoS > 0

Paho MQTT client, max in-flight messages for QoS > 0

Working with MQTT protocol in Java usually means using Eclipse Paho FOSS library as a client (it’s even used by Spring for MQTT support in Spring Messaging).

Using Paho to send messages with Quality of Service (QoS) bigger than zero though might result in error/exception “Too many publishes in progress” in case many messages are sent in short period of time.

The straightforward fix to that is of-course not to use QoS other than zero, but there are other ways to remedy that problem.

The cause of the problem is that for every message sent with QoS > 0 the message is stored on client side, sent to the broker, and removed from client side after the broker confirms receiving it (or resent if it doesn’t – presumably, within certain time frame).

Such stored messages are called “in-flight” in Paho terminology, and they can be stored either in file or in memory – depending on which MqttClientPersistence implementation you choose to use (default is in file AFAIK).

The problem is no matter what storage you choose, there is a limit for number of in-flight messages, which by default is… 10 messages. This seems uber-restrictive to me.

This “max in-flight” limit could not be changed in Paho until version 1.1.0 – which was released in the end of January 2015, but still Paho JavaDocs on Eclipse website are for version 1.0.0 and don’t reflect the change in API.

The change itself is this – class org.eclipse.paho.client.mqttv3.MqttConnectOptions got a new method – public void setMaxInflight(int maxInflight).

Now one can set max in-flight to up to 65535. The limitation is dictated by Paho assigning IDs to each MQTT “packet” it’s about to send (even though I don’t see any compelling reason to do that until the actual sending, and between client and broker there’s always only 1 in-fligh message AFAIK, all other messages just wait on client until the one gets sent – to preserve sending order), and MQTT protocol uses 16 bit IDs for MQTT packets with QoS > 0.

Thus setting max in-flight in Paho above 65535 can and will result in different error – Internal error, caused by no new message IDs being available.

Since there are more “packets” than just outgoing MQTT messages (there are some ping/ack packets Paho stores internally together with packets for in-flight messages) – setting max in-flight to 65535 is not recommended – some space for IDs should be left for those service packets to avoid same “Internal error, caused by no new message IDs being available” exception.

Still, setting max in-flight to 65000 or so (or even 32768, half of possible IDs space) will give one much more space for queued to be published QoS 1/2 messages than default limit of 10, which might just allow one to use QoS 1 where otherwise fallback to QoS 0 had to be done.

That’s all. Hope this helps.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s