I\'m running an Express.js application using Socket.io for a chat webapp and I get the following error randomly around 5 times during 24h. The node process is wrapped in for
A simple tcp server I had for serving the flash policy file was causing this. I can now catch the error using a handler:
# serving the flash policy file
net = require("net")
net.createServer((socket) =>
//just added
socket.on("error", (err) =>
console.log("Caught flash policy server socket error: ")
console.log(err.stack)
)
socket.write("<?xml version=\"1.0\"?>\n")
socket.write("<!DOCTYPE cross-domain-policy SYSTEM \"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd\">\n")
socket.write("<cross-domain-policy>\n")
socket.write("<allow-access-from domain=\"*\" to-ports=\"*\"/>\n")
socket.write("</cross-domain-policy>\n")
socket.end()
).listen(843)
I had the same issue and it appears that the Node.js version was the problem.
I installed the previous version of Node.js (10.14.2) and everything was ok using nvm (allow you to install several version of Node.js and quickly switch from a version to another).
It is not a "clean" solution, but it can serve you temporarly.
I had resolved this problem by:
npm update
in terminal to update npm.After that I tried the same npm command and the good thing was it worked out. I wasn't sure it is that simple.
I am using CENTOS 7
I just figured this out, at least in my use case.
I was getting ECONNRESET
. It turned out that the way my client was set up, it was hitting the server with an API call a ton of times really quickly -- and it only needed to hit the endpoint once.
When I fixed that, the error was gone.
I had this Error too and was able to solve it after days of debugging and analysis:
For me VirtualBox (for Docker) was the Problem. I had Port Forwarding configured on my VM and the error only occured on the forwarded port.
The following observations may save you days of work I had to invest:
-> figure out if something is messing around with your network (-settings), like VMs, Firewalls etc., this is probably the cause of the problem.
I was facing the same issue but I mitigated it by placing:
server.timeout = 0;
before server.listen
. server
is an HTTP server here. The default timeout is 2 minutes as per the API documentation.