[FIXED] Conn and Subscription Close()/Unubscribe() could not be retried #360
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If a connection is closed, or a subscription is closed or unsubscribed, and an error occurs at the protocol level, for instance getting a timeout or the NATS connection is currently disconnected, etc.. the Close()/Unsubscribe() calls would return an error but the user would not be able to invoke them again, in the sense that these calls would bail out early because those objects were already marked as closed. This was problematic because if an application closes a connection for instance but gets a timeout, then there is no way for the application to really try to tell the server that the connection should be closed. (same for subscription). This PR let the user call Close()/Unsubscribe() if the library failed to get a response from the server (likely timeout or NATS communication issue). However, if the server returns an error, then the connection/ subscription will be considered fully closed and user won't be able to call the close API again. The alternative would be to set the object as fully closed only in case of total success... Signed-off-by: Ivan Kozlovic <[email protected]>
kozlovic
added a commit
that referenced
this pull request
Nov 17, 2021
In PR #360, we changed the default behavior of connection Close() in that if the library failed to sent the close protocol or received its response, the Close() could be retried. In order to do that, the underlying NATS connection would not be closed. This has side-effects in that the NATS connection would be left opened or possibly reconnect when an user would have previously called Close(), not check error, and expect NATS connection to be closed. The introduction of this option allow the default behavior to remain the same, and users that do want to be able to call Close() again on a failed call will need to set this option when creating the connection. Signed-off-by: Ivan Kozlovic <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If a connection is closed, or a subscription is closed or unsubscribed,
and an error occurs at the protocol level, for instance getting a
timeout or the NATS connection is currently disconnected, etc..
the Close()/Unsubscribe() calls would return an error but the user
would not be able to invoke them again, in the sense that these
calls would bail out early because those objects were already marked
as closed.
This was problematic because if an application closes a connection for
instance but gets a timeout, then there is no way for the application
to really try to tell the server that the connection should be closed.
(same for subscription).
This PR let the user call Close()/Unsubscribe() if the library failed
to get a response from the server (likely timeout or NATS communication
issue). However, if the server returns an error, then the connection/
subscription will be considered fully closed and user won't be able
to call the close API again. The alternative would be to set the
object as fully closed only in case of total success...
Signed-off-by: Ivan Kozlovic [email protected]