Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Maximum messages inflight on Java asynchronous client

Ian, just a few thoughts:

(1) internal limit. Maybe this isn't important if #2 / #3 were improved
(2) flow control between consumer / producer
(3) persistence

A very popular Java library which owes a lot to Eric Meijer and Rx Extensions from Microsoft implements something called 'reactive pull backpressure':


Perhaps some ideas on flow control between producer / consumer can be inspired from this.

They also have a few other mechanisms in place to depending on needs (also mentioned above):
* onBackPressureBuffer
* onBackPressureDrop
* onBackPressureBlock

So perhaps:

* persistence is used for QoS 1/2, but maybe it should also be allowed for QoS0 if in memory buffer is overflowing (or just queue it on disk regardless and have fast-path to client if its available to send right away).
* allow the user to pick a strategy like above (buffer, drop, or block)
* implement something like reactive backpressure (consumer pulls when overloaded).

Hope this provides some ideas,
-Alex


> Date: Wed, 4 Feb 2015 14:47:03 +0000
> From: icraggs@xxxxxxxxxxxxxxxxxxxxxxx
> To: paho-dev@xxxxxxxxxxx
> Subject: [paho-dev] Maximum messages inflight on Java asynchronous client
>
> Hello all,
>
> when the Java asynchronous API was written, it used the same maximum
> message inflight limit for QoS 1/2 messages as the synchronous client,
> of 10.
>
> We've had some people report hitting that limit and wanting it to go
> higher. In the C asynchronous and _javascript_ clients, there is no such
> limit, because you can use the callbacks to count how many outstanding
> messages there are, so you can implement any strategy yourself.
>
> We are fixing this under bug 456855:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=456855.
>
> My first suggestion was to allow the limit to be configurable, which is
> what Bin has implemented, with the default as it was previously, for
> maximum backward compatibility. However it has been suggested that
> removing the limit altogether would be better (in fact then it would be
> the MQTT message limit, 64k).
>
> Does anyone have any strong feelings either way, or other thoughts or
> suggestions?
>
> Thanks
>
> --
> Ian Craggs
> icraggs@xxxxxxxxxx IBM United Kingdom
> Paho Project Lead; Committer on Mosquitto
>
> _______________________________________________
> 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

Back to the top