As an alternative, in applications for the C asynchronous client, I
count the difference between the number of publish calls and the
number of onSuccess callbacks, so I know how many messages are
"inflight". But I guess calling getPendingDeliveryTokens() is
easier :-)
Ian
On 10/03/2014 02:08 PM, Marc L Cohen
wrote:
The limit is not well
published, but it is 10 currently. I use
client.getPendingDeliveryTokens().length
to determine how many messages
are in flight and to decide if I need to wait.
Marc L. Cohen
MessageSight Test/Development
Internet:mlcohen@xxxxxxxxxx
also at:teddybbear@xxxxxxx
(512) 286-5744 (T/L 363-5744)
FAX (512) 973-4293
 Alex Helder
---10/03/2014 03:49:51 AM---I often find myself in one of the
following scenarios with the Paho Java client, with no elegant
sol
From: Alex Helder
<alexrhelder@xxxxxxxxxxx>
To: "paho-dev@xxxxxxxxxxx"
<paho-dev@xxxxxxxxxxx>
Date: 10/03/2014 03:49 AM
Subject: [paho-dev] Java MqttAsyncClient
Flow Control / Offline Buffering
Sent by: paho-dev-bounces@xxxxxxxxxxx
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
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
|
