WebSocket-Node icon indicating copy to clipboard operation
WebSocket-Node copied to clipboard

ECONNRESET random crash

Open panshengjie opened this issue 4 years ago • 4 comments

I've solving this crash for a quite long time. pretty hard to trace.

my env: ubuntu 16.04 x64 node10 websocket 1.0.31, using WebSocketServer autoAcceptConnections=true problem: random crash on error ECONNRESET , at TCP.onread(net.js: 656:25)

out applicantion runs on mobile robot running all day&night . crash happen randomly in some weeks or month

I've checked your code. Here is my guess: when a new client is autoAccepted, a WebSocketConnection is created. it remove all error hander of socket at the end of constructor (WebSocketConnection.js line 140 ). However it didn't install a error handler immediately , which I think is the reason for crash.
In code WebSocketRequest.js line 450, it seems event listeners are installed after a success response write. If socket error happens between that , the app crash.

panshengjie avatar Jan 05 '21 06:01 panshengjie

Makes sense. Can you create a PR?

ibc avatar Jan 05 '21 22:01 ibc

#408

panshengjie avatar Jan 06 '21 03:01 panshengjie

I commented in the pull request noting that the proposed fix does work, however, I also thought I'd mention that this error can be handled from the application code by attaching an error listener to the underlying ConnectionRequest socket:

wsServer.on('request', (connectionRequest) => { connectionRequest.socket.on('error', (err) => { console.log(err); }); });

Obviously a fix implemented in the library itself is preferable in the long term.

ASBaj avatar Sep 08 '21 19:09 ASBaj

this isn't doing anything, now we just log the error twice

alin1771 avatar Nov 19 '21 13:11 alin1771

Hello, is there any plan to merge this into the library? We are using 1.0.34 on nodejs v16.18.1 and occasionally seeing the ECONNRESET error (and causing a crash)

Error: write ECONNRESET at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16) at TLSWrap.writeAsciiString () at handleWriteReq (node:internal/stream_base_commons:63:21) at writeGeneric (node:internal/stream_base_commons:149:15) at TLSSocket.Socket._writeGeneric (node:net:905:11) at TLSSocket.Socket._write (node:net:917:8) at writeOrBuffer (node:internal/streams/writable:391:12) at _write (node:internal/streams/writable:332:10) at TLSSocket.Writable.end (node:internal/streams/writable:611:17) at TLSSocket.Socket.end (node:net:679:31) at WebSocketRequest.reject (/opt/nisient/lib/node/node_modules/websocket/lib/WebSocketRequest.js:500:17) at WebSocketServer. (/opt/nisient/lib/node/stage1c.js:17:5852) at WebSocketServer.emit (node:events:513:28) at WebSocketServer.handleUpgrade (/opt/nisient/lib/node/node_modules/websocket/lib/WebSocketServer.js:224:14) at Server.emit (node:events:513:28) at Server. (/usr/lib/node_modules/pm2/node_modules/@pm2/io/build/main/metrics/httpMetrics.js:152:37)

rgillan avatar Mar 03 '23 00:03 rgillan

I think @alin1771 is correct that this patch does not do anything because between the time when the error listeners are removed and the websocket error listeners added there is no async code so isn't it impossible for an uncaught error to occur until the next tick? However, I'm not a node expert..

colinmollenhour avatar Jun 09 '23 04:06 colinmollenhour

All good and agreed. We put an error listener on the request.socket that catches the error.

rgillan avatar Jun 13 '23 21:06 rgillan