[FIXED] Repeated timeout of Flush/FlushTimeout and inability to dispatch #322
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 when the client issues a Flush() or FlushTimeout(), the client library times out when at the same time it receives the PONG, there is a possibility that the processing of the PONG gets the channel it needs to notify from the array while the routine waiting on that notification is done waiting but has not yet removed the channel from the array. This will lead to processPong() to be stuck in a chan send, which is blocking the readLopp, which will ultimately lead to server closing this connection. The solution is to create a buffererd channel (of size 1). We should not simply do a `select` when trying to notify because we don't want to miss the notification if the routine sending the PING is not yet in the select to consume the notification. Resolves #321
|
lgtm |
wallyqs
approved these changes
Oct 20, 2017
TheGhoul21
pushed a commit
to TheGhoul21/nats.go
that referenced
this pull request
Jun 20, 2024
Previously, it would attempt to use the host from the url, which includes the `[]` which `to_socket_addrs()` didn't know how to deal with. This change strips the `[]`s. Fixes: nats-io#322 Signed-off-by: Jesse Szwedko <[email protected]> Co-authored-by: Tomasz Pietrek <[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 when the client issues a Flush() or FlushTimeout(), the client
library times out when at the same time it receives the PONG, there
is a possibility that the processing of the PONG gets the channel
it needs to notify from the array while the routine waiting on
that notification is done waiting but has not yet removed the
channel from the array. This will lead to processPong() to be
stuck in a chan send, which is blocking the readLopp, which will
ultimately lead to server closing this connection.
The solution is to create a buffererd channel (of size 1). We
should not simply do a
selectwhen trying to notify because wedon't want to miss the notification if the routine sending the PING
is not yet in the select to consume the notification.
Resolves #321