I often find myself in one of the following scenarios with the Paho Java client, with no elegant solution:
1) A Producer creates messages to publish regardless of whether the Paho client is connected to a broker or not. I must queue these messages myself when not connected to a broker.
2) When connected to a broker, flow control using the MqttAsyncClient's publish() method is awkward. This method can throw an exception for QoS1/QoS2 messages if the maximum number of 'inflight' messages is reached - but this limit is not knowable, and there is no flow control or back-pressure to prevent inadvertently tripping over it. The only way to establish flow control is to immediately block after publish() using IMqttToken.waitForCompletion() - effectively turning this into the blocking client.
I think the solution to this is that the Paho client API should /appear/ as a queue to the user. If the client is offline, QoS 0,1,2 messages can be added to the queue. When the client connects to the broker, it can consume the persisted queue.
Additionally:
* Internally, the queue and MqttClientPersistence should be the same store.
* The user should be able to provide an implementation of a queue which can be configured in several ways: (1) in memory or persisted (this is possible now), (2) bounded or unbounded