MQTT broker module for Vert.x

[Tim Fox]

I was alerted to this on Twitter:

https://github.com/giovibal/vertx-mqtt-broker-mod

Looks very interesting :)

[Giovanni Baleani]

Hi, I'm the developer,

today I've committed some bugfixes related to persistence, some trivial (main-based) test I uset to develop, 

corrected startup documentation and update roadmap.

[Giovanni Baleani]

Still working on it: 

https://github.com/giovibal/vertx-mqtt-broker-mod

now based on vert.x 3, added support for MQTT v3.1.1, clustering, OAuth2, multitenancy, docker build...  several bugs fixed

Il giorno martedì 27 maggio 2014 12:59:27 UTC+2, Tim Fox ha scritto:

[Tim Fox]

Very cool!

A few questions:

1. Is it fully non blocking?
2. Is there a client too?
3. Does it bridge to the Vert.x event bus? (*)

* If bridged to the event bus, if the MQTT server receives a message from a client it can automatically forward it to an Vert.x event bus address. So you can basically have Vert.x event bus listeners talking directly to MQTT clients.

Also, the other way, if an MQTT client is subscribed to a topic, then a Vert.x event bus message sent to a mapped address will be received by the MQTT client.

BTW. Don't forget to get it added to the vertx-awesome page :)

https://github.com/vert-x3/vertx-awesome

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Giovanni Baleani]

Thank you for your reply and your interest in this project, 

here the responses:

1. Is it fully non blocking?

Yes, there is only one worker-verticle for OAuth2 token verification via SOAP with wso2 identity server; but in the near future this piece will be plug-able.

Sometime, under stress-tests, we see warning messages about thread blocked for more than 2000 millis, we are investigating on it.

2. Is there a client too?

No, but often we use paho java client inside a (worker) verticle.

 

3. Does it bridge to the Vert.x event bus? (*)

In the old version (vert.x 2.1) we used one to one mapping between mqtt topic and event bus address.

The new architecture was refactored to use only one address for all mqtt messages on event bus.

We choose this architecture because a plugin/verticle can treat all messages easily by subscribing at only one address on the event-bus.

With one single address, one can program a verticle that can - for example - persist all messages without discover or know a-priori all the addresses/topics that are used, or easily write a bridge to another mqtt broker, or to kafka.

But if there is a method on vert.x3 to subscribe at a group of event-bus addresses with a filter (for example address/*), please let me know.

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/SVbvO3oQv0M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Giovanni Baleani