|
In the C client libraries, the
synchronous API has a limit of 10 (or 1 -- see "reliable")
inflight messages, but the asynchronous client has no limit apart
from running out of the 64k MQTT msgids (as does the _javascript_
API). The publish call of the synchronous API blocks when it hits
the limit.
This seems like a reasonable approach, as the aim of the
synchronous API is to make writing of application programs simple,
while the aim of the async API is to never block. It is also
quite easy in the async API to limit the number of inflight
messages you have by subtracting the number of message delivered
callbacks from the number of successful publication calls made.
The only drawback is that it makes it easy in the async API to end
up with a large number (but still a lot less than 64k) of inflight
messages, which is not efficient. The client librararies aren't
intended to be databases.
Ian
On 25/11/13 16:29, Marc L Cohen wrote:
I would
definitely like to see a settable max for inflight messages.
10 is very easy to hit for a high performance client. Offline
buffering sounds nice, and could be taken advantage of in
mobile, I suppose, but I personally would prefer to see the
limit removed first.
Would like to
hear from others....
Marc
Sent from my iPad
there are a couple of ideas
that have been
discussed and interested in what you think:
1) to make it easier to set
to the max
inflight messages
2) to provide a proper
offline buffering
capability. The current inflight messages feature only
works when
the client is connected. The buffer mode would allow a
configurable
number of messages to be sent while the client is not
connected
All the best
Dave
From:
Marc L Cohen <mlcohen@xxxxxxxxxx>
To:
"General
development
discussions for paho project" <paho-dev@xxxxxxxxxxx>
Date:
24/11/2013 01:08
Subject:
Re: [paho-dev]
Maximum number of inflight messages exceeded
Sent by:
paho-dev-bounces@xxxxxxxxxxx
Are there any thoughts about
making
that number flexible or settable by the programmer?
Marc L Cohen
Sent from my iPad
On Nov 23, 2013, at 5:21 AM, "Ian Craggs" <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
wrote:
> Hi Tito,
>
> in the Java client, there is an internal setting of 10
QoS 1 or 2
> messages that can be "in-flight" (unfinished protocol
exchanges)
at one
> time. It is a temporary condition that will be
resolved once
the
> sending of at least one message has been completed.
>
> So the application should try again in a short period
of time. If
you
> are using the async API, you could wait until a
callback is made telling
> you that the next message has been sent.
>
> It does not apply to QoS 0 messages as there are no
ACKs nor message
ids
> in that case.
>
> Ian
>
> On 23/11/13 00:33, Tito Cheriachan wrote:
> > Hi all,
> >
> > I am using the paho mqtt java client and I was
sending out a
lot of messages every second , but the mqtt connection was
not established
, then I encountered an exception like maximum number of in
flight messages
exceeded.
> >
> > 1. Does this happen if the mqtt is not able to
push out messages
to the broker ?
> >
> > 2.will it happen on all qos levels ?
> >
> > 3.On what all scenarios will this occur.
> > _______________________________________________
> > paho-dev mailing list
> > paho-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/paho-dev
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/paho-dev
> _______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales
with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire PO6
3AU
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
|
