Skip to content
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

Better handle ws errors #28

Merged
merged 8 commits into from
Jul 6, 2015
Merged

Better handle ws errors #28

merged 8 commits into from
Jul 6, 2015

Conversation

rmg
Copy link
Member

@rmg rmg commented Jul 3, 2015

Improves testability of WS channel as well as better handling of disconnects and unset acknowledgements.

Connect to strongloop-internal/scrum-nodeops#755

@rmg
Copy link
Member Author

rmg commented Jul 3, 2015

@piscisaureus does this cover the problem you are describing in #26?

Also, PTAL, I think this is ready for review.

@rmg
Copy link
Member Author

rmg commented Jul 3, 2015

@slnode test please

rmg added a commit to strongloop/strong-supervisor that referenced this pull request Jul 3, 2015
If the WS control channel emits an error, it disconnects. It is up to
the client to re-connect to the server when this happens.

Depends on changes in strongloop/strong-control-channel#28 to improve
SCC's own handling of errors and disconnects, as well as improvements
to the testability of WS channels because of new events.
@rmg
Copy link
Member Author

rmg commented Jul 6, 2015

@piscisaureus the connect and connection are 2 different events for 2 different scenarios.

@piscisaureus
Copy link
Contributor

@piscisaureus the connect and connection are 2 different events for 2 different scenarios.

In any case the ws.once('open', emit) handler should be removed in _detach(), because it's possible that a socket is detached before it is connected and if that were to happen the internal state gets messed up.

Other than that, lgtm.

@piscisaureus piscisaureus assigned rmg and unassigned piscisaureus Jul 6, 2015
rmg added 8 commits July 6, 2015 13:50
Emit 'connect' every time it establishes a connection with 'connect()'
as a client. The event includes the WebSocket instance mainly for
testing purposes.

Emit 'connection' with a WebSocket instance every time a new WS client
connects to our channel. The channel can only be connected to a single
client at a time, so the WebSocket instance is mainly for testing.
Previously we were only closing if not already closed.. or at least
that was the intention. Because there was a typo (readystate instead of
readyState) we were actually _always_ closing. Obviously there is no
harm, so let's just make it official.
Also don't attempt to send if we are not connected. This is mostly a
simplification.
The check for whether other messages were queued was inverted. The
result was that as long as we were the last one to send a message, then
we would never even bother to check if we had any outstanding acks to
send. The effect is that which ever side of the channel was the last
one to send a request (responses don't count) was the only one that
initiate a graceful disconnect.
per-message deflate could be useful for some of our messages, and it is
even enabled by default, but it is also a little bit buggy, so we
disable it so we don't end up with 'write after end' errors from the
underlying socket.

This is most certainly a bug in WS.
@rmg rmg force-pushed the better-handle-ws-errors branch from 8cc88fb to 5ba8ffa Compare July 6, 2015 20:57
@rmg
Copy link
Member Author

rmg commented Jul 6, 2015

@slnode test please

rmg added a commit that referenced this pull request Jul 6, 2015
@rmg rmg merged commit cf9d515 into master Jul 6, 2015
@rmg rmg deleted the better-handle-ws-errors branch July 6, 2015 21:41
@rmg rmg removed the #review label Jul 6, 2015
rmg added a commit to strongloop/strong-supervisor that referenced this pull request Jul 7, 2015
If the WS control channel emits an error, it disconnects. It is up to
the client to re-connect to the server when this happens.

Depends on changes in strongloop/strong-control-channel#28 to improve
SCC's own handling of errors and disconnects, as well as improvements
to the testability of WS channels because of new events.
rmg added a commit to strongloop/strong-supervisor that referenced this pull request Jul 7, 2015
If the WS control channel emits an error, it disconnects. It is up to
the client to re-connect to the server when this happens.

Depends on changes in strongloop/strong-control-channel#28 to improve
SCC's own handling of errors and disconnects, as well as improvements
to the testability of WS channels because of new events.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants