Ian,
I don't think Paho Clients are and should be highly scalable. I
personally are in favor of having rock-solid MQTT clients for real-world
productive usage. So from my point of view, 3) can be dropped and be
replaced with the mission goal of having production-ready rock-solid
clients.
We have written several load tests with different approaches and the
truth is, that we always had to write our own MQTT clients for that.
Speaking of Java clients, there is the fusesource-mqtt client which is
more scalable than the Paho Java implementation but it has many
concurrency bugs when using under load, so I always recommend using
Paho.
If there is interest for such a highly scalable and concurrent
implementation of a Java MQTT client with a nice fluent API, we would
consider bringing it to the Paho project. Beside the nice fluent API,
this MQTT client also has a "low-level" interface for doing things like
sending "raw" MQTT messages, which may be useful for testing the
behaviour of MQTT servers. So you can for instance emulate faulty MQTT
client behaviour with that. This client unfortunately doesn't run on
Android (afaik) and needs at least Java 5. So I would not see a
competing MQTT Java client to the current Paho one but a complementary
one for testing tool implementations. Internally we're using this
library heavily for our HiveMQ integration and specification tests and
for distributed load tests.
Best,
Dominik
Ian Craggs wrote:
Hello all,
just scanning the web page, I noticed it describes three attributes
of Paho:
1) for constrained networks
2) devices and embedded platforms
3) highly scalable
where 3) is described as:
Paho focuses on highly scalable implementations that will
integrate with a wide range of middleware, programming and
messaging models.
I agree with the first two, but is it really true that Paho
implementations are or should be highly scalable? What does this
really mean? Several times I have heard of people wanting to create
load tests for their MQTT server, but as far as I am aware none of
the Paho libraries is specifically designed for that
purpose. While they may be capable of doing so, their design is not
likely to be optimal. When I am writing a client-side library, the
highest priority is usually making it small.
This claim might give rise to expectations which we can't fulfil,
unless anyone has a different interpretation? If so, I think we
need to explain.
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Committer on Paho, 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
|