Can we share MqttClient between verticles?

[alamothe]

Read the docs and issues but haven't found this answered anywhere.

Is it safe to share MqttClient between verticles? Or should each verticle have its own MqttClient?

How is this different/same compared to HttpClient?

Thank you

[pigbayspy]

No, you should not do this. I think it can not be shared by different verticle instances.

Please see this eclipse-vertx/vert.x#1248 (comment)

[vietj]

I think you can share a client between verticles, however handler will be called on a single event-loop that created the client.

[pigbayspy]

I think you can share a client between verticles, however handler will be called on a single event-loop that created the client.

In my impression, each verticle should have its own client. Is it a good way to share client between different verticle?

[vietj]

I think it depends what you want to do and how many connections you want to open to the mqtt server. Publishing to the server can be done from any verticle.

…

On Thu, Aug 4, 2022 at 9:27 AM Yin Hang ***@***.***> wrote: I think you can share a client between verticles, however handler will be called on a single event-loop that created the client. In my impression, each verticle should have its own client. Is it a good way to share client between different verticle? — Reply to this email directly, view it on GitHub <#219 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABXDCT2GJP2T7JUVQYTCWTVXNWG3ANCNFSM5XPHD3RA> . You are receiving this because you commented.Message ID: ***@***.***>

[alamothe]

That's a huge gotcha, as it almost certainly means you have to deal with multi-threaded programming, which defeats the purpose of using Vert.x in the first place. So from the user perspective in 99% of cases the clients should not be shared.

However appreciate you explaining the constraints clearly.

[vietj]

it's not really multi threaded because all processing message is done in a single event-loop.

Also I think the API usability could be improved and deal with multiple contexts, e.g now we have subscribe and process which are two separate operations:

client.publishHandler(s -> {
  System.out.println("There are new message in topic: " + s.topicName());
  System.out.println("Content(as string) of the message: " + s.payload().toString());
  System.out.println("QoS: " + s.qosLevel());
}).subscribe("rpi2/temp", 2);

instead we could have:

client.subscribe("rpi2/temp", 2, s -> {
  System.out.println("There are new message in topic: " + s.topicName());
  System.out.println("Content(as string) of the message: " + s.payload().toString());
  System.out.println("QoS: " + s.qosLevel());
};

the message would be delivered on the context of the subscriber and not on the context of the connection.

If the client is confined within a verticle, it would behave like it does currently.

There are other operations that could be improved with such correlations.

[vietj]

See #228