一次会话后，开始出现两次read ECONNRESET at exports._errnoException (util.js:870:11) at TCP.onread (net.js:544:26) 的异常信息，接着就报出Error: socket hang up at createHangUpError (_http_client.js:200:15) at Socket.socketOnEnd (_http_client.js:285:23) at emitNone (events.js:72:20) at Socket.emit (events.js:166:7) at endReadableNT (_stream_readable.js:905:12) at nextTickCallbackWith2Args (node.js:437:9) at process._tickCallback (node.js:351:17)， 这一般是我在会话中哪个地方没处理好呢？找了好半天，一直没头绪啊，没头绪。。。
ECONNRESET 是 socket 那层出错，跟 node 没啥关系哈~ http://lzy.iteye.com/blog/383884 碰到了就去看为什么会出错，检查网络。
ECONNRESET
该错误被描述为“connection reset by peer”，即“对方复位连接”，这种情况一般发生在服务进程较客户进程提前终止。当服务进程终止时会向客户 TCP 发送 FIN 分节，客户 TCP 回应 ACK，服务 TCP 将转入 FIN_WAIT2 状态。此时如果客户进程没有处理该 FIN （如阻塞在其它调用上而没有关闭 Socket 时），则客户 TCP 将处于 CLOSE_WAIT 状态。当客户进程再次向 FIN_WAIT2 状态的服务 TCP 发送数据时，则服务 TCP 将立刻响应 RST。一般来说，这种情况还可以会引发另外的应用程序异常，客户进程在发送完数据后，往往会等待从网络IO接收数据，很典型的如 read 或 readline 调用，此时由于执行时序的原因，如果该调用发生在 RST 分节收到前执行的话，那么结果是客户进程会得到一个非预期的 EOF 错误。此时一般会输出“server terminated prematurely”－“服务器过早终止”错误。
@magicdawn ECONNRESET 是 socket 层出错这没问题. 但你不能说因此跟 node 没啥关系…
这种 Socket 错误其实非常常见普遍, 只要正确捕获并处理就行.
楼主提到程序崩溃, 显然就是那种没有 listen error 事件, 导致 Socket 的触发的 Error Event (就是这里 at exports._errnoException (util.js:870:11)) 没有监听的handler而直接扔出来了, 然后就是 uncaughtException 导致崩溃.
所以, @jiangliqin 到底你代码哪里没处理好, 得见着代码才知道的. 上面给的这些 stack 信息, 因为OS底层的 socket 事件上来的, 所以根本看不出任何问题.
有时候出现这个错误的时候, socket 层面的 connection 已经由其他模块自动处理了(比如 http, mongodb 等). error 事件只是起到通知作用. 这种的一般不需要你再做什么. 甚至直接 on(‘error’, function(){}) 都行. 只要保证 error 事件有监听就行.
另外一些时候, 可能你需要不同的底层事件来做出不同的处理策略. 比如最近遇到的就是需要自己封装一个接口非常简单干净的 nsq 的 writer 客户端. 这种情况下, 底层的 error 事件, close 事件都得对应做相应的处理, 来实现断开自动重连, 消息发送失败自动重试, 重试次数或频率超过最大值需要 destory 等, 都需要基于这些事件.
之前做的前后分离项目, Java后端出JSON API + Node.js做前端。有时半夜出现 ECONNRESET(查日志知道的, 用express next(err))。 查到了, 就认为是Java server波动，然而又没辙。。。
嘿嘿… 理解!
机房网络状况波动导致延迟增高把 node 进程 RSS 内存憋上去了, 也把人搞得心惊胆战… 然并卵. 既然不听 error 会崩, 在没有大碍的情况下那就勉为其难的随便听听吧…
@Chunlin-Li 我有对process的uncaughtException异常进行捕捉，但是http没有监听error，这样只是捕捉两次uncaughtException后就崩溃报错了
@jiangliqin 如果捕捉了 uncaughtException 异常应该不会完全崩掉的啊… 除非是在你的 uncaughtException 的错误 handler 中又引发了异常… 再或者是从外部 SIGKILL 强杀了.
