-
Notifications
You must be signed in to change notification settings - Fork 5
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
TLSSocket.onHangUp produces fatal error #8
Comments
So, TLSSocket emits an event (probably "error"), and we end up in ClientSocket._disconnect() (from one of these two). As we make our way up the chain, we end up in ClientSocket.connect, which calls into TLS's `connect()' here. And somehow this is producing an unhandled error, even though we handle the error here. O_o |
Ok, this was kind of an obnoxious error. The problem (and fix) is here. Basically, I was trying to be aggressive about garbage collection - removing all the listeners (which have references to the ClientSocket by way of closures), and setting @_socket to null. The problem here was, one of these sockets was continuing to emit errors after we'd removed all the listeners and discarded the socket, which is how we were running into this problem. It's a little bit worrisome that this socket, which should be dead at this point, continues to push errors. Hopefully we're not leaking sockets. -_- |
Fixed in [email protected] (and I updated the dependency in [email protected].) |
🤦♂️ Fixed even better in 1.0.6: f32cc4a |
similar to my comments on #6, however:
restarting log stash service causes (expected) disconnect, AND an "unhandled" socket hang up,
I've used longjohn to help trace the issue and sourced the (possible) root of the problem to ClientSocket and/or Client
This error breaks the log queue during disconnect, since it just takes the whole app with it.
trace (invoked by restarting the log stash service):
The text was updated successfully, but these errors were encountered: