Remove race condition when server closes connection #256
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
When server closes connection right after having sent some frames, those are ignored by the client. Frames are lost because they are processed in a nextTick/setImmediate callback, thus socket close event may arrive before they are actually processed.
|
Yes, this is a potentially challenging/sticky situation. I went back and forth on this a few times in the initial design/implementation of the library. It'll take some careful changes to implement this correctly. |
|
Is this still an issue? At least the tests should get merged no? |
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.
When server closes connection right after having sent some frames, those are ignored by the client. Frames are lost because they are processed in a nextTick/setImmediate callback, thus socket close event may arrive before they are actually processed.
Added a test that reproduces the error, on my computer it states that it received only 6 frames. I wonder if that could be computer-dependent so if that does not reproduce, try increasing to
var count = 100;to something much larger.The fix proposed here does not look right as it disables something done on purpose, as per the comment above (that's why I just commented out the line and not fixed the now useless bound method, I don't think this will be the real solution). Trying to delay socket end handling leads to socket errors, and I did not find anything better, so at least putting something that makes tests green. Welcome to any idea!