Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Message loss with higher load - eclipse paho mqtt client
Paul,

There's nothing in MQTT 3.1.1 that doesn't allow servers or clients to just drop QoS 0 whenever they want to; loaded or unloaded. And for 1/2, there's nothing to stop a server doing TCP (or other layer) traffic shaping, reduced CPU time, removing from a epoll/poll/whatever schedule, not reading the tcp buffer, etc.

However, a server may disconnect a client. Sometimes there's very little else the spec permits. The great challenge is in dealing with out-of-resource scenarios - the spec as it stands has no way of communicating 'sorry, can't do this right now / or ever '.


Raphael Cohn
Chief Architect, stormmq
Co-Chair, OASIS MQTT Standard
Secretary, OASIS AMQP Standard
raphael.cohn@xxxxxxxxxxx
+44 7590 675 756

UK Office:
Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657
StormMQ.com


On 8 November 2013 11:22, Paul Fremantle <paul.fremantle@xxxxxxxxxx> wrote:
Ian

Can you point me at the wording that would compel this? This seems a bad decision to me. Generally I'd like to see the following behaviour:

QOS0: the server could just drop messages when overloaded.
QOS1/2: I'd like the server to apply tcp back-pressure on the client until less loaded. Disconnecting seems a bit drastic.

Paul


On 8 November 2013 10:13, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
With the new standard, if this sort of limit is reached, I think we will be compelled to disconnect the client.

Ian


On 08/11/13 09:51, Roger Light wrote:
Hi Kasun,

My guess is that you're using mosquitto with QoS 1 or 2 messages.
Current versions of mosquitto limit the number of messages a client
can have inflight and queued in both directions. The default limit is
20 inflight and 100 queued. You may wish to increase these limits.
There is also a valid argument that the client should limit the
incoming message rate and the server should just accept what is being
sent.

Cheers,

Roger


On Fri, Nov 8, 2013 at 6:50 AM, Kasun Weranga
<kasungunathilake@xxxxxxxxx> wrote:
Hi all,

I am experience some message loss with high load when using eclipse paho
mqtt client. I have subscribed to a set of topics (clients/+) and I did some
load testing using eclipse paho mqtt client. I saw my subscriber only
receiving first 120 messages when I publish messages to (clients/+) topics -
Message publishing rate is above 400 messages per second.
Is there any configuration that I need to set for higher load. How can I
solve above issue.
Appreciate any help on solving this issue.

Thanks and Regards,
Kasun.





--
Kasun Weranga Gunathilake.
mobile: +6594230423
LinkedIn: http://sg.linkedin.com/in/kasunwg
blog: http://kasunweranga.blogspot.com/


_______________________________________________
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



--
Paul Fremantle
Part-time PhD student - School of Computing
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev


Back to the top