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
