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

[mqtt] Changed MQTT client from Paho to HiveMQ #1125

Merged
merged 11 commits into from
Nov 5, 2019
Merged

Conversation

J-N-K
Copy link
Member

@J-N-K J-N-K commented Oct 13, 2019

Supersedes #929.

Signed-off-by: Jan N. Klug jan.n.klug@rub.de

@J-N-K
Copy link
Member Author

J-N-K commented Oct 13, 2019

Points to discuss:

  • Should we define a netty core-feature? We have a lot of bundles that use netty and - at the moment - all can use 4.1.34.Final.
  • How shall we select Mqtt3/5 client? This requires a reconnection in any case, but setter/getter or constructor enhancement? We could also use Mqtt3 for the existing constructor and define a new one which allows the selevtion of v3/v5

@wborn
Copy link
Member

wborn commented Oct 13, 2019

Thanks for pushing this forwards. 👍

I think adding a netty feature is a good addition. Personally I would go for an additional constructor if the only configuration option is v3/v5. To future proof choosing between many options using a builder might be another option. But it's probably overkill if there's just this one configuration option.

Copy link
Member

@davidgraeff davidgraeff left a comment

Choose a reason for hiding this comment

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

Thank you very much for this PR.

I've added a few inline comments.


// use defaults when not provided by caller
qos = qos == null ? this.qos : qos;
retain = retain == null ? this.retain : retain;
Copy link
Member

Choose a reason for hiding this comment

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

You are using deprecated class fields in this non-deprecated method.

Copy link
Member Author

Choose a reason for hiding this comment

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

No way to remin backward compatible otherwise. When we remove the retain-setter/getter, we can default that to false (what is the default now, if not explicitely set otherwise).

@@ -890,7 +888,7 @@ public void publish(String topic, byte[] payload, MqttActionCallback listener) {
* exceptionally on an error or with a result of false if no broker connection is established.
*/
public CompletableFuture<Boolean> publish(String topic, byte[] payload) {
Copy link
Member

Choose a reason for hiding this comment

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

Mark this deprecated maybe? Implicitly it uses deprecated class fields ("retain", "qos").

Copy link
Member Author

Choose a reason for hiding this comment

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

It'll use the default (QoS 0 and retain false) after the getter/setter is removed.

Copy link
Member Author

Choose a reason for hiding this comment

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

While we are discussing deprecation: What is the use-case for subscribeRaw and unsubscribeRaw? If there are no subscribers, why should the connection subscribe to a topic?

Copy link
Member

Choose a reason for hiding this comment

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

I think it had to do keep alive subscriptions. But not sure anymore, I should have documented those methods better. Did you encounter any usages?

Copy link
Member Author

@J-N-K J-N-K Oct 22, 2019

Choose a reason for hiding this comment

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

Not in openhab2-addons and not in openhab-core

Copy link
Member

Choose a reason for hiding this comment

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

Deprecating or better removing should be fine then. I also do not see any benefit in keeping this API.

}
return f;
CompletableFuture<Boolean> future = new CompletableFuture<>();
client.publish(topic, payload, retain, qos).whenComplete((m, t) -> {
Copy link
Member

@davidgraeff davidgraeff Oct 20, 2019

Choose a reason for hiding this comment

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

Why can't you use the clients future directly as return value? Maybe add the (unnecessary) boolean argument to the future to make it compatible?

This conversion stuff happening here right now is probably more inefficient than carrying a useless boolean in the type signature.

Copy link
Member Author

@J-N-K J-N-K Oct 20, 2019

Choose a reason for hiding this comment

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

The clients return different futures: CompletableFuture<Mqtt3Publish> and CompletableFuture<Mqtt5Publish>.

Copy link
Member

@davidgraeff davidgraeff left a comment

Choose a reason for hiding this comment

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

Looks good so far, one last inline comment from my side

@J-N-K
Copy link
Member Author

J-N-K commented Nov 3, 2019

@openhab/core-maintainers If we postpone this again, we‘ll be too close to the next milestone to merge it. And I would feel uncomfortable to add this to a release without having it tested in a milestone before.

@kaikreuzer
Copy link
Member

I'm ok with merging, but I would like to see @davidgraeff's final approval on it.
Plus, it seems you need to rebase :-)

Copy link
Member

@davidgraeff davidgraeff left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@cweitkamp cweitkamp left a comment

Choose a reason for hiding this comment

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

Thanks you for the work. I am afraid I cannot say much about the topic itself but I added some code style comments. Feel free to resolve them.

if (t == null) {
future.complete(true);
} else {
logger.info("Error subscribing to topic {}", topic, t);
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is an error, why not log an error?

Copy link
Member Author

Choose a reason for hiding this comment

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

I changed the wording and upgraded to warn. error is too much IMO, this does not affect the funtion of the other topics or the connection.

case 2:
return MqttQos.EXACTLY_ONCE;
default:
throw new IllegalArgumentException();
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it make sense to use a specific message for this exception?

@J-N-K
Copy link
Member Author

J-N-K commented Nov 4, 2019

Please note that https://github.com/openhab/openhab2-addons/pull/6245 needs to be merged to keep the tests in addons running.

J-N-K added 11 commits November 4, 2019 18:48
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
Copy link
Contributor

@cweitkamp cweitkamp left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks.

@cweitkamp cweitkamp added rebuild Triggers the Jenkins PR build and removed rebuild Triggers the Jenkins PR build labels Nov 4, 2019
@kaikreuzer kaikreuzer merged commit 07d10db into openhab:master Nov 5, 2019
@cweitkamp cweitkamp added this to the 2.5 milestone Nov 5, 2019
@cweitkamp cweitkamp added the enhancement An enhancement or new feature of the Core label Nov 5, 2019
@cweitkamp cweitkamp changed the title move MQTT client from Paho to HiveMQ Changed MQTT client from Paho to HiveMQ Dec 2, 2019
@cweitkamp cweitkamp changed the title Changed MQTT client from Paho to HiveMQ [mqtt] Changed MQTT client from Paho to HiveMQ Dec 3, 2019
@kaikreuzer kaikreuzer removed the enhancement An enhancement or new feature of the Core label Dec 13, 2019
Rosi2143 pushed a commit to Rosi2143/openhab-core that referenced this pull request Dec 26, 2020
@J-N-K J-N-K deleted the hivemq branch February 9, 2021 17:10
splatch pushed a commit to ConnectorIO/copybara-hab-core that referenced this pull request Jul 11, 2023
Signed-off-by: Jan N. Klug <jan.n.klug@rub.de>
GitOrigin-RevId: 07d10db
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants