Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an MQTT client session, which allows to automatically re-connect. #197

Open
wants to merge 20 commits into
base: master
Choose a base branch
from

Conversation

ctron
Copy link
Contributor

@ctron ctron commented May 17, 2021

Motivation:

Trying to fix: smallrye/smallrye-reactive-messaging#1181

Conformance:

Your commits should be signed and you should have signed the Eclipse Contributor Agreement as explained in https://github.com/eclipse/vert.x/blob/master/CONTRIBUTING.md
Please also make sure you adhere to the code style guidelines: https://github.com/vert-x3/wiki/wiki/Vert.x-code-style-guidelines

@ctron
Copy link
Contributor Author

ctron commented May 17, 2021

This is a first draft for adding an MQTT client session, for clean session = true only.

@ctron ctron force-pushed the feature/mqtt_client_session_1 branch 8 times, most recently from ec88f5d to d68fc58 Compare May 17, 2021 12:31
@ctron ctron force-pushed the feature/mqtt_client_session_1 branch from d68fc58 to f54f3bd Compare May 17, 2021 12:36
@ctron ctron marked this pull request as ready for review May 17, 2021 16:04
Signed-off-by: Jens Reimann <[email protected]>
Copy link
Member

@cescoffier cescoffier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

* @return The duration to wait.
*/
private Duration nextDelay() {
return Duration.ofSeconds(10);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be configurable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it should :)

* @param reason The reason message.
*/
private void closeConnection(final String reason) {
closeConnection(new IOException(reason));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be better to use a VertxEception, as anyway the stack trace is useless.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

ctron added 2 commits May 18, 2021 09:06
Signed-off-by: Jens Reimann <[email protected]>
Signed-off-by: Jens Reimann <[email protected]>
@ppatierno
Copy link
Member

@ctron @cescoffier tbh I do really not agree to have this implementation into the MQTT client. It's not MQTT specification we are implementing here, where the concept of "session" is completely different. It shoud be fixed at smallrye level. Reconnection it's not a matter of the MQTT client itself but of the app using the client. The MQTT client has to implement the 3.1.1 specification and nothing more; any other concern is at application level.

@ctron
Copy link
Contributor Author

ctron commented May 18, 2021

I am sorry, but I completely disagree. Also, in smallrye/smallrye-reactive-messaging#1181 we already agreed that this should land in the client implementation of vertx.

The MQTT client session is an opinionated construct, and this lives in its own class, re-using the existing client.

People are asking for this functionality for a while. And instead of making people's live harder, we should make their lives easier, if was expect them to adopt our technologies.

@ppatierno
Copy link
Member

My strong opinion is that an MQTT client should implement MQTT specification and nothing more. Any other aspects is out of the scope of the client. If people want something we can provide them examples or as I said implement it at smallrye level. Starting to mix not MQTT specification stuff into an MQTT client would drive to create a monster. Everyone can start to ask features that are not part of the spec.

@ppatierno
Copy link
Member

People asking for this feature for a while and not doing that in their own applications mean people who don't know about MQTT protocol and maybe they are using the wrong protocol or in the wrong way. We should educate people and not putting everything just because they ask something. This client should be a pure 3.1.1 specification implementation. Stop.

@ctron
Copy link
Contributor Author

ctron commented May 18, 2021

@cescoffier @vietj Do we move on as agreed upon? Or do I just ditch the whole effort and look for alternatives elsewhere?

@ppatierno
Copy link
Member

Or do I just ditch the whole effort and look for alternatives elsewhere?

What are the alternatives we are talking about? Why the feature cannot be into smallrye if you are using it? Why if you can't continue to use the MQTT client and adding the reconnect logic into your application. I really don't think that Eclipse Paho MQTT implementations put some stuff out of specification inside the client. The same doesn't happen for other protocols like AMQP 1.0 as well.

/**
* An MQTT client session.
*/
public interface MqttClientSession {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be annotated with @VertxGen

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tried that, and it fails with:

[ERROR] diagnostic: /home/jreimann/git/vertx-mqtt/src/main/java/io/vertx/mqtt/MqttClientSession.java:41: error: Could not generate model for io.vertx.mqtt.MqttClientSession: @VertxGen can only declare methods and not io.vertx.mqtt.MqttClientSession
public interface MqttClientSession {
       ^

Any ideas what could cause that?

@ppatierno
Copy link
Member

@vietj please take a look at the discussion going on smallrye/smallrye-reactive-messaging#1181, thanks!

Signed-off-by: Jens Reimann <[email protected]>
@vietj
Copy link
Contributor

vietj commented May 19, 2021 via email

ctron added 2 commits May 19, 2021 18:11
This required to move out the inner classes and to create interfaces
for the event classes too.

Signed-off-by: Jens Reimann <[email protected]>
Signed-off-by: Jens Reimann <[email protected]>
@ctron
Copy link
Contributor Author

ctron commented May 19, 2021

Yes, that was the problem. Also I had to create interfaces for the even classes. I had to re-organize that bit. You might not like the way I did that. Just let me know how, and I well re-organize and re-name.

@vietj
Copy link
Contributor

vietj commented May 19, 2021 via email

@ppatierno
Copy link
Member

@vietj @ctron instead of continuing to review ignoring me, can we continue the discussion on the issue please?

@vietj
Copy link
Contributor

vietj commented May 19, 2021

@ppatierno I did not spend much time on the review yet and did a first pass on the code, I did not spot your comments

ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 27, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 27, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 27, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 27, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 27, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 27, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 27, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 28, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 28, 2021
ctron added a commit to ctron/smallrye-reactive-messaging that referenced this pull request May 31, 2021
@ppatierno
Copy link
Member

@ctron based on this smallrye/smallrye-reactive-messaging#1228 got merged, I guess that we can close this one?

@ctron
Copy link
Contributor Author

ctron commented May 31, 2021

@ctron based on this smallrye/smallrye-reactive-messaging#1228 got merged, I guess that we can close this one?

If you really think this PR isn't an improvement to the vertx-mqtt client, then feel free to close it.

@ppatierno
Copy link
Member

We all know my opinion :-) I will double check with @vietj ... I do really think that you fixed the issue at the right level.

@cescoffier
Copy link
Member

I don't believe that the connector is at the right level. It's a temporary solution as we need to get things moving.
Typically, being in a connector avoid annoying not using Reactive Messaging to use the feature.

@ctron
Copy link
Contributor Author

ctron commented May 31, 2021

I don't believe that the connector is at the right level. It's a temporary solution as we need to get things moving.
Typically, being in a connector avoid annoying not using Reactive Messaging to use the feature.

I should have made myself clear. I fully agree with what @cescoffier said. I also think that having re-connect capabilities is definitely an improvement, like other MQTT clients have as well. Making this optional is fine, but it should come "out of the box" from an MQTT client.

Actively deciding against having the feature, is a failure in my opinion.

@ppatierno
Copy link
Member

@ctron please provide me a concrete example of a client doing this but not just a reconnect as Paho does because I have already said it's ok with me. I am not ok of tracing all subscriptions in something called "session" on the client (even when "session" is a completely different thing in MQTT spec).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

When an MQTT connection dies, it fails with a NPE and never reconnects
4 participants