That could be a good option. Would that be a permanent incubator
project, that you mentioned previously?
Ian
On 09/04/2014 06:13 PM, Ian Skerrett
wrote:
Ian
Would
it make sense to have a Paho sub-project that is for MQTT
testing. This could also be the location for the MQTT
interop test cases that you have been working on.
Dominik,
thanks for your comments. I agree with you entirely.
I definitely think there is an interest in a highly scalable
MQTT client for load testing MQTT servers. I know several
projects who have written their own MQTT load testing
clients.
One approach I have taken in the past is to network RSMBs
together with their bridges: one RSMB bridging to 500
others, each with 500 bridge connections to the MQTT server
under test. That means you can easily spread out the
second-level RSMBs over several machines if you need to, and
I could build it very quickly. That approach should work
with Mosquitto too.
As I see it, the only potential risk of contributing your
client is confusion about which to use, which could be
minimized by putting it under "tools", "utilities" or a
similar category. Personally, I would be very happy to see
the contribution.
Ian
On 09/04/2014 04:15 PM, Dominik
Obermaier wrote:
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
_______________________________________________
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
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
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Committer on Paho, Mosquitto
|
