Multiple sequential errors cause multiple reconnection attempts #125
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
dpatty
changed the title
dpatty
changed the title
|
Thanks for contributing! |
icy-fish
added a commit
to icy-fish/eventsource
that referenced
this pull request
May 21, 2020
Since the PR EventSource#125 fixed duplicate connections after reconnection by using a `connectionInProgress` lock to avoid function `connect()` be called duplicately. But it forgot to release the `connectionInProgress` lock when request error happends, in that case, our client can only retry for 1 time and never get the lock again. So it's needed to release the `connectionInProgress` lock when error happends. Signed-off-by: icy_fish <keith519@qq.com>
icy-fish
added a commit
to icy-fish/eventsource
that referenced
this pull request
May 21, 2020
Since the PR EventSource#125 fixed duplicate connections after reconnection by using a `connectionInProgress` lock to avoid function `connect()` be called duplicately. But it forgot to release the `connectionInProgress` lock when request error happends, in that case, our client can only retry for 1 time and never get the lock again. So it's needed to release the `connectionInProgress` lock when error happends. Signed-off-by: icy_fish <keith519@qq.com>
icy-fish
added a commit
to icy-fish/eventsource
that referenced
this pull request
May 24, 2020
Since the PR EventSource#125 fixed duplicate connections after reconnection by using a `connectionInProgress` lock to avoid function `connect()` be called duplicately. But it forgot to release the `connectionInProgress` lock when request error happends, in that case, our client can only retry for 1 time and never get the lock again. So it's needed to release the `connectionInProgress` lock when error happends. Signed-off-by: icy_fish <keith519@qq.com>
This was referenced Mar 18, 2021
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.
I was seeing some weird behavior with a spotty server connection.
When the server caused some sort of parse error or network exchange error, the EventSource client would attempt to reconnect to the server (via
onConnectionClosed).The problem was that in between recognizing the network error, and actually reconnecting, there was a chance for another error to also force a reconection attempt. This would result in a new connection attempted for each error in that window. Thus 1 connection to the server with 2 errors would result in 2 new connections to the server. (see images below)
Repeat this a few times and you get a compounding problem:
At some point in this process the server began interfering with the error states meaning some connections were kept open without an error, but others would continue to proliferate double connections
I expected to only see a single re-connection after each error. After the fix this is the behavior.
