vert-x3 / vertx-mqtt

Vert.x MQTT
Apache License 2.0
184 stars 86 forks source link

Can we share MqttClient between verticles? #219

Closed alamothe closed 2 years ago

alamothe commented 2 years ago

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 commented 2 years ago

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

Please see this https://github.com/eclipse-vertx/vert.x/issues/1248#issuecomment-165722769

vietj commented 2 years ago

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

pigbayspy commented 2 years ago

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 commented 2 years ago

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 https://github.com/vert-x3/vertx-mqtt/issues/219#issuecomment-1204872060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCT2GJP2T7JUVQYTCWTVXNWG3ANCNFSM5XPHD3RA . You are receiving this because you commented.Message ID: @.***>

alamothe commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

See https://github.com/vert-x3/vertx-mqtt/issues/228