-
Notifications
You must be signed in to change notification settings - Fork 105
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
TCP connection leaking on closing connection #65
Comments
Side note: this issue has been hotfixed on node-red-contrib-cip-ethernet-ip by calling |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current Behavior
When calling the (undocumented)
Controller.destroy()
function on an unconnected session, the connection and the controller's instance don't get actually destroyed, leaking the instance itself a TCP socket handle (including its file descriptor). When done multiple times, this leads to a file descriptor starvation, causing any subsequent I/O on the whole process to fail with EMFILE.Expected Behavior
Calling
Controller.destroy()
should completely destroy the instance, without leaking any instance nor file descriptorsPossible Solution (Optional)
The root cause is that
Controller.destroy()
tries to write a unregister session packet before actually destroying the underlying socket. When the packet can't be written (like when the connection hasn't completed in the first place), the socket doesn't get destroyed.Some possible solutions:
close()
function: TheSocket.destroy()
function, according to the Node.JS API, is meant to be called when we want to ultimately kill the socket. TheSocket.close()
is meant to gracefully close the connection. This node could follow the standard having aController.close()
for gracefully closing the connection (like writing the unregister session packet and sending TCP FIN), and lettingController.destroy()
to forcefully destroy the socket and connection. This has been discussed on Ambiguous resource closing and examples do not close after completion. #53. Downside is breaking the current API.Context
This issue has surfaced on node-red-contrib-cip-ethernet-ip when connecting to a PLC that is not always online. When the PLC is offline, the above mentioned issue happens, but as the node keeps trying to connect to the PLC (in case it is back online), a lot of file descriptors are leaked, leading to a file descriptor starvation and compromising the whole Node-RED process.
Steps to Reproduce (for bugs only)
Controller
, connecting to a dummy IP address (so that it doesn't connect)Controller
instance and try again./proc/xxxx/fd
, where xxxx is the PID of the node.js process)TCP
,TCPWrapper
andController
instances can also be checked by using Chrome's Developer Console.Your Environment
npm list
- e.g. 1.0.6): 1.2.5node --version
- e.g. 9.8.0): 10.15.3The text was updated successfully, but these errors were encountered: