-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
@piscisaureus does this cover the problem you are describing in #26? Also, PTAL, I think this is ready for review. |
@slnode test please |
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.
@piscisaureus the |
In any case the ws.once('open', emit) handler should be removed in Other than that, lgtm. |
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.
8cc88fb
to
5ba8ffa
Compare
@slnode test please |
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.
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.
Improves testability of WS channel as well as better handling of disconnects and unset acknowledgements.
Connect to strongloop-internal/scrum-nodeops#755