-
Notifications
You must be signed in to change notification settings - Fork 160
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
Feature/automatic resubscribe #398
Conversation
e3d20ec
to
09efec5
Compare
...ain/java/com/hivemq/client/internal/mqtt/handler/publish/outgoing/MqttAckSingleFlowable.java
Show resolved
Hide resolved
… to publishes) Subscription and global flows are not expired when reconnect is enabled
Removed Flowable/FluxWithSingleCombine which had concurrency issues
Restored Flowable/FluxWithSingleCombine and fixed concurrency issues
…andwidth when restoring subscriptions)
…s more consistent: MqttIncomingPublishFlow(s) and MqttSubscribedPublishFlow(s))
7b7a86e
to
828edad
Compare
src/main/java/com/hivemq/client/internal/mqtt/handler/subscribe/MqttSubscriptionHandler.java
Show resolved
Hide resolved
src/main/java/com/hivemq/client/internal/mqtt/handler/subscribe/MqttSubscriptionHandler.java
Show resolved
Hide resolved
subscriptionIdentifiersAvailable = connectionConfig.areSubscriptionIdentifiersAvailable(); | ||
|
||
if (!hasSession) { | ||
incomingPublishFlows.getSubscriptions().forEach((subscriptionIdentifier, subscriptions) -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this bahavior should be configurable somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What should be configurable?
If you use automatic reconnect and the server lost the session between the connection loss and a successful reconnect, why would you not want to resubscribe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually feedback from users who are confused by SessionExpiredExceptions when they use automatic reconnect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use case: You are in extremely constrained networks and want to be very precise on which data you send and when you send it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same is true for resending publishes.
Isn't automatic reconnect the wrong choice if you want to have control over everything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same is true for resending publishes.
I did not know that. But I would argue that the same logic applies.
I feel like the connect is something else. As it is the basis for everything afterwards. And in the connect there are possibilities to influence the behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So would a config to disable automatic resubscribe be enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah for a start I think so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added configuration option: Reconnector.resubscribeIfSessionExpired
(default true)
Also added a similar option for republishing: Reconnector.republishIfSessionExpired
(default false)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good. The question about the configurability of the resubscribe must be resolved.
…ibedPublishFlowTree, reasons: the first is tightly coupled to the MqttOutgoingQosHandler the second is similar to a collection which is instantiated
Motivation
Resolves #297 and resolves #288
This is a prerequisite for proper implementation of manual acknowledgement and message persistence.
Changes