node.js - traduccion - Nodo JS ECONNRESET

nodejs request error econnreset

Question

Estoy ejecutando una aplicación Express js con socket.io para una aplicación web de chat y recibo el siguiente error de forma aleatoria unas 5 veces durante las 24 horas. El proceso del nodo está envuelto para siempre y se reinicia inmediatamente.

El problema es que el reinicio rápido saca a mis usuarios de sus habitaciones y nadie quiere eso.

El servidor web es proxy por HAProxy. No hay problemas de estabilidad de socket, solo se utilizan los websockets y flashsockets transportes. No puedo reproducir esto a propósito.

Este es el error con el nodo v0.10.11:

events.js:72
        throw er; // Unhandled ''error'' event
              ^
Error: read ECONNRESET     //alternatively it s a ''write''
    at errnoException (net.js:900:11)
    at TCP.onread (net.js:555:19)
error: Forever detected script exited with code: 8
error: Forever restarting script for 2 time

EDITAR (2013-07-22)

Se agregaron el controlador de errores del cliente socket.io y el controlador de excepciones no recuperado. Parece que éste atrapa el error:

process.on(''uncaughtException'', function (err) {
  console.error(err.stack);
  console.log("Node NOT Exiting...");
});

Entonces sospecho que no es un problema de socket.io sino una solicitud http a otro servidor que hago o una conexión mysql / redis. El problema es que la pila de errores no me ayuda a identificar mi problema de código. Aquí está la salida del registro:

Error: read ECONNRESET
    at errnoException (net.js:900:11)
    at TCP.onread (net.js:555:19)

¿Cómo sé qué causa esto? ¿Cómo saco más provecho del error?

Ok, no muy detallado pero aquí está el seguimiento de pila con "longjohn":

Exception caught: Error ECONNRESET
{ [Error: read ECONNRESET]
  code: ''ECONNRESET'',
  errno: ''ECONNRESET'',
  syscall: ''read'',
  __cached_trace__:
   [ { receiver: [Object],
       fun: [Function: errnoException],
       pos: 22930 },
     { receiver: [Object], fun: [Function: onread], pos: 14545 },
     {},
     { receiver: [Object],
       fun: [Function: fireErrorCallbacks],
       pos: 11672 },
     { receiver: [Object], fun: [Function], pos: 12329 },
     { receiver: [Object], fun: [Function: onread], pos: 14536 } ],
  __previous__:
   { [Error]
     id: 1061835,
     location: ''fireErrorCallbacks (net.js:439)'',
     __location__: ''process.nextTick'',
     __previous__: null,
     __trace_count__: 1,
     __cached_trace__: [ [Object], [Object], [Object] ] } }

Aquí sirvo el archivo de política de socket flash:

net = require("net")
net.createServer( (socket) =>
  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)

¿Puede ser esta la causa?

Answer 1

Es posible que ya lo hayas adivinado: es un error de conexión.

"ECONNRESET" significa que el otro lado de la conversación TCP cerró bruscamente su final de la conexión. Esto se debe probablemente a uno o más errores de protocolo de aplicación. Puede mirar los registros del servidor API para ver si se queja de algo.

Pero dado que también está buscando una forma de verificar el error y potencialmente depurar el problema, debería echar un vistazo a " ¿Cómo depurar un error de bloqueo de socket en NodeJS? " Que se publicó en en relación con una pregunta similar.

Solución rápida y sucia para el desarrollo :

Use longjohn , obtendrá trazas de pila largas que contendrán las operaciones asíncronas.

Solución limpia y correcta : Técnicamente, en el nodo, cada vez que emita un evento de ''error'' y nadie lo escuche, lo lanzará . Para hacer que no se lance, ponga un oyente en él y manéjelo usted mismo. De esa manera puedes registrar el error con más información.

Para tener un oyente para un grupo de llamadas, puede usar domains y también detectar otros errores en tiempo de ejecución. Asegúrese de que cada operación asíncrona relacionada con http (Servidor / Cliente) esté en un contexto de domains diferente en comparación con las otras partes del código, el dominio escuchará automáticamente los eventos de error y lo propagará a su propio controlador. Así que solo escuchas ese controlador y obtienes los datos de error. También obtienes más información de forma gratuita.

EDITAR (2013-07-22)

Como escribí anteriormente:

"ECONNRESET" significa que el otro lado de la conversación TCP cerró bruscamente su final de la conexión. Esto se debe probablemente a uno o más errores de protocolo de aplicación. Puede mirar los registros del servidor API para ver si se queja de algo.

Lo que también podría ser el caso: en momentos aleatorios, el otro lado está sobrecargado y simplemente mata la conexión como resultado. Si ese es el caso, depende de a qué te estás conectando exactamente ...

Pero una cosa es segura: de hecho, tiene un error de lectura en su conexión TCP que causa la excepción. Puede verlo observando el código de error que publicó en su edición, que lo confirma.

Answer 2

Intente agregar estas opciones a socket.io:

const options = { transports: [''websocket''], pingTimeout: 3000, pingInterval: 5000 };

Espero que esto ayude !

Answer 3

Me enfrentaba al mismo problema pero lo mitigaba colocando:

server.timeout = 0;

antes de server.listen . server es un servidor HTTP aquí. El tiempo de espera predeterminado es de 2 minutos según la documentación de la API .

Answer 4

Otro caso posible (pero raro) podría ser si tiene comunicaciones de servidor a servidor y ha configurado server.maxConnections a un valor muy bajo.

En el núcleo lib net.js del nodo, llamará a clientHandle.close() que también causará el error ECONNRESET:

if (self.maxConnections && self._connections >= self.maxConnections) {
  clientHandle.close(); // causes ECONNRESET on the other end
  return;
}

Answer 5

Resolví el problema simplemente conectándome a una red diferente . Ese es uno de los posibles problemas.

Como se mencionó anteriormente, ECONNRESET significa que la conversación de TCP cerró bruscamente su final de la conexión.

Su conexión a Internet puede estar impidiéndole conectarse a algunos servidores. En mi caso, estaba tratando de conectarme a mLab (servicio de base de datos en la nube que aloja las bases de datos MongoDB). Y mi ISP lo está bloqueando.

Answer 6

Sí, su publicación del archivo de política definitivamente puede causar el bloqueo.

Para repetir, simplemente agregue un retraso a su código:

net.createServer( function(socket) 
{
  for(i=0; i<1000000000; i++);
  socket.write("<?xml version=/"1.0/"?>/n")
…

... y use telnet para conectarse al puerto. Si desconecta telnet antes de que la demora haya expirado, obtendrá un bloqueo (excepción no detectada) cuando socket.write arroja un error.

Para evitar el bloqueo aquí, simplemente agregue un controlador de errores antes de leer / escribir el socket:

net.createServer( function(socket) 
{
  for(i=0; i<1000000000; i++);
  socket.on(''error'', function() { console.log("error"); });
  socket.write("<?xml version=/"1.0/"?>/n")

Cuando pruebe la desconexión anterior, recibirá un mensaje de registro en lugar de un bloqueo.

Y cuando hayas terminado, recuerda eliminar el retraso.

Answer 7

También obtengo el error ECONNRESET durante mi desarrollo, la forma en que lo soluciono es al no usar nodemon para iniciar mi servidor, simplemente use "node server.js" para iniciar mi servidor solucionado mi problema.

Es raro, pero funcionó para mí, ahora nunca vuelvo a ver el error ECONNRESET.

Answer 8

También tuve este error y pude resolverlo después de días de depuración y análisis:

mi solución

Para mí, VirtualBox (para Docker) era el problema. Tuve el reenvío de puertos configurado en mi máquina virtual y el error solo ocurrió en el puerto reenviado.

conclusiones generales

Las siguientes observaciones pueden ahorrarle días de trabajo que tuve que invertir:

• Para mí, el problema solo ocurrió en las conexiones de localhost a localhost en un puerto. -> Comprobar cambiar cualquiera de estas constantes resuelve el problema.
• Para mí, el problema solo ocurrió en mi máquina -> permitir que alguien más lo intente.
• Para mí, el problema solo ocurrió después de un tiempo y no se pudo reproducir de manera confiable
• No se pudo inspeccionar mi problema con ninguno de los nodos o las herramientas expresas (depuración). -> no pierdas el tiempo en esto

-> averigüe si hay algún problema con su red (-settings), como máquinas virtuales, firewalls, etc., esta es probablemente la causa del problema.

Answer 9

Tuve un problema similar en el que las aplicaciones comenzaron a fallar después de una actualización de Node. Creo que esto se puede remontar a la versión del nodo v0.9.10 de este artículo:

• red: no suprimir ECONNRESET (Ben Noordhuis)

Las versiones anteriores no darían error en las interrupciones del cliente. Una interrupción en la conexión del cliente produce el error ECONNRESET en el nodo. Creo que esta funcionalidad está pensada para Node, por lo que la solución (al menos para mí) fue para manejar el error, lo que creo que cometió en excepciones no detectadas. Aunque lo manejo en el controlador net.socket.

Puedes demostrar esto:

Haga un servidor de socket simple y obtenga Node v0.9.9 y v0.9.10.

require(''net'')
    .createServer( function(socket) 
    {
           // no nothing
    })
    .listen(21, function()
     {
           console.log(''Socket ON'')
    })

Inícielo usando v0.9.9 y luego intente enviar FTP a este servidor. Estoy usando FTP y el puerto 21 solo porque estoy en Windows y tengo un cliente FTP, pero no tengo un cliente telnet a mano.

Entonces desde el lado del cliente, simplemente rompa la conexión. (Solo estoy haciendo Ctrl-C)

No debería ver NINGÚN ERROR cuando se usa el Nodo v0.9.9, y ERROR cuando se usa el Nodo v.0.9.10 en adelante.

En producción, utilizo v.0.10. Algo y sigue dando el error. Una vez más, creo que esto está pensado y la solución es manejar el error en su código.

Answer 10

Tuvo el mismo problema hoy. Después de algunas investigaciones, encontré una --abort-on-uncaught-exception muy útil --abort-on-uncaught-exception node.js. No solo proporciona un seguimiento de pila de errores mucho más detallado y útil, sino que también guarda el archivo principal en el bloqueo de la aplicación, lo que permite una mayor depuración.

Answer 11

Un simple servidor TCP que tenía para servir el archivo de política flash estaba causando esto. Ahora puedo detectar el error usando un controlador:

# 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)