Para mí, esto suena como un problema de red fuera de Node.js, este error "ECONNRESET" es cuando la conexión remota a Node.js cierra el socket inesperadamente.

¿Estás usando un proxy entre Node y Redis?

¿Qué versión del servidor Node / node_redis / Redis?

Dudo que el agente NewRelic esté involucrado, pero siempre puedes intentar reproducir sin el agente y ver si eso soluciona el problema. cc / @wraithan

Esas líneas son simplemente CLS haciendo lo suyo. Con más de una reproducción podría descartar por completo al agente de New Relic. Pero estoy relativamente seguro de que esto no lo hemos causado nosotros.

Eliminé el agente NewRelic, el problema persiste. Aprox. cada 3 minutos tengo este accidente. A continuación se muestran los registros como referencia.

events.js: 72
lanzador; // Evento de 'error' no controlado
^
Error: conexión de Redis a redis1.tfs. tfs: 6379 falló - leer ECONNRESET
en RedisClient.on_error (/var/www/a/b/c/node_modules/redis/index.js:196:24)
en Socket.(/var/www/a/b/c/node_modules/redis/index.js:106:14)
en Socket.emit (events.js: 95: 17)
en net.js: 441: 14
en process._tickDomainCallback (node.js: 486: 13)
error: el script detectado para siempre salió con el código: 8
error: intento de reinicio del script # 50

Además, estoy usando Node.JS - v0.10.35, node_redis - 0.12.1 y Redis - 2.8.4.
Estoy accediendo a Redis directamente a través de IP en Node.

Yo también estaba enfrentando este problema, pero lo resolví después de darme cuenta de que ayer estaba jugando con mi archivo /etc/hosts por alguna otra razón. Faltaba:

127.0.0.1 localhost

@ ayazpasha2434 , es posible que la solución no sea la misma para usted, pero como otros están insinuando, definitivamente está fuera del nodo y en el env / shell / OS / VM. Da un paso atrás y míralo.

@sarathms Tengo esta asignación en mi archivo de hosts. Sin embargo, la máquina Redis en mi caso es remota. Solo verifiqué, también tengo dicho mapeo de localhost en la máquina Redis. Aún así, el problema no está resuelto.

También me enfrento al mismo problema. Aquí está la salida de la consola

events.js: 72
lanzador; // Evento de 'error' no controlado
^
Error: conexión de Redis a pub-redis-10606.us-east-1-1.1.ec2.garantiadata. com: 10606 falló - leer ECONNRESET en RedisClient.on_error (C: UsersGigiDesktopeduknow_api_ver_1authnode_m
odulesredisindex.js: 196: 24)
en Socket.(C: UsersGigiDesktopeduknow_api_ver_1authnode_modulesredisindex.js: 106: 14)
en Socket.emit (events.js: 95: 17)
en net.js: 441: 14
en process._tickCallback (node.js: 442: 13)

@ ayazpasha2434 Esta línea resolvió mi error

client.on ('error', function (err) {console.error (err)})

@ ayazpasha2434 ¿ @Waterloo tuvo la respuesta correcta para ti?

Parecía haber un problema con su conexión de red y no parece ser un problema con node redis. Agregar el controlador de errores debería ser suficiente para que la aplicación ya no se bloquee (y siempre debe estar adjunta).

Encontré este problema cuando publico un http (use post) en el servidor JAVA. {[Error: read ECONNRESET]
código: 'ECONNRESET',
errno: 'ECONNRESET',
syscall: 'leer',
respuesta: indefinido}
Error: leer ECONNRESET
en las exportaciones._errnoException (util.js: 856: 11)
en TCP.onread (net.js: 546: 26)
doble devolución de llamada!
POST / user_archives / crear / guardar 500 45.306 ms - 386
Error: leer ECONNRESET
en las exportaciones._errnoException (util.js: 856: 11)
en TCP.onread (net.js: 546: 26)

@ biggu0 No estoy seguro de qué conexión tiene esto con node_redis. Para obtener más información sobre ECONNRESET, es posible que desee consultar stackoverflow .

Hola ,
También estamos viendo este problema. Observamos que podría deberse a redis SNAPSHOTTING. Siempre que redis toma instantáneas y se almacena en el disco, la conexión se restablece. Para demostrar mi valía, comparo los registros de la aplicación con los registros de depuración de Redis y los tiempos coinciden exactamente.

a continuación se muestra la configuración de instantáneas en redis.conf
guardar 900 1
ahorra 300 10
guardar 60 10000

Háganos saber si estamos haciendo algo mal.

También me enfrento a problemas de conexión con frecuencia.

ERR en RedisClient.emit (events.js: 188: 7)
ERR en RedisClient.on_error (/home/vcap/app/node_modules/redis/index.js:394:14)
ERR en RedisClient.(/home/vcap/app/server.js:28:13)
ERR en emitErrorNT (net.js: 1281: 8)
ERR en Socket.(/home/vcap/app/node_modules/redis/index.js:272:14)
ERR en process._tickCallback (interno / proceso / next_tick.js: 98: 9)
ERR Error: conexión de Redis a XXXXXXXX: XXXXX falló - leer ECONNRESET
ERR en TCP.onread (net.js: 572: 26)
ERR en _combinedTickCallback (interno / proceso / next_tick.js: 74: 11)
ERR en emitOne (events.js: 96: 13)
ERR en las exportaciones._errnoException (util.js: 1022: 11)
ERR en Socket.emit (events.js: 188: 7)

Después de recibir el error, se vuelve a conectar automáticamente.
¿Cuál puede ser el problema de perder la conexión?

Hola Waterloo,
Donde pones esta declaración client.on ('error', function (err) {console.error (err)})
y creo que esta declaración es solo para consolar su error, nada más.
¿Es realmente utilizable?
Por favor, dame tus pensamientos lo antes posible.

¡¡¡Gracias por adelantado!!!

Hola

También estoy enfrentando el mismo problema

events.js: 160
lanzador; // Evento de 'error' no controlado
^

Error: leer ECONNRESET

Esto resolvió mi problema con:

1. Inhabilité la supervisión de todos mis procesos (nueva reliquia, apm elástico ...)
2. Utilicé este código
   `` `Javascript
   process.on ('uncaughtException', function (err) {
   console.error (err.stack);
   console.log ("El nodo NO sale ...");
   });

También estoy enfrentando este problema. Estoy usando el marco sails.js con un gancho, por lo que solo hay una conexión al servidor de redis al iniciar el servicio de nodo, usaremos el objeto de velas globales para acceder y trabajar con redis

redisClient = redis.createClient({
    host: redisConfig.host,
    port: redisConfig.port,
    db: redisConfig.db,
    retry_strategy: (retryOptions) => {
        if (retryOptions.error && retryOptions.error.code === 'ECONNREFUSED') {
            // End reconnecting on a specific error and flush all commands with
            // a individual error
            return new Error('The server refused the connection');
        }

        if (retryOptions.total_retry_time > 1000 * 60 * 60) {
            // End reconnecting after a specific timeout and flush all commands
            // with a individual error
            return new Error('Retry time exhausted');
        }

        if (retryOptions.attempt > 3) {
            // End reconnecting with built in error
            return undefined;
        }

        sails.log.debug('Handling redis retry strategy', {
            error: retryOptions.error,
            totalRetryTime: retryOptions.total_retry_time,
            attempt: retryOptions.attempt
        });

        // Reconnect after
        return Math.min(retryOptions.attempt * 100, 3000);
    }
});

Aquí está el rastro de pila del error
AbortError: Se perdió la conexión de Redis y se canceló el comando. Es posible que se haya procesado en RedisClient.flush_and_error (/var/sample-app/node_modules/redis/index.js:362:23)n en RedisClient.connection_gone (/ var / sample-app / node_modules / redis / index. js: 664: 14) n en RedisClient.on_error (/var/sample-app/node_modules/redis/index.js:410:10)n en Socket.(/var/sample-app/node_modules/redis/index.js:279:14)n en emitOne (events.js: 116: 13) n en Socket.emit (events.js: 211: 7) n en emitErrorNT ( internal / streams / destroy.js: 66: 8) n en /var/sample-app/node_modules/async-listener/glue.js:188:31n en args. (función anónima) (/ usr / lib / node_modules / pm2 /node_modules/event-loop-inspector/index.js:138:29)n en _combinedTickCallback (internal / process / next_tick.js: 139: 11) n en process._tickDomainCallback (internal / process / next_tick.js: 219: 9 ) n en process.fallback (/var/sample-app/node_modules/async-listener/index.js:563:15).

Nuestra aplicación de nodo se ejecuta en un contenedor Docker y se conectará al servidor Redis instalado en una instancia EC2 de linux.

También nos enfrentamos al mismo problema, pero aquí colocamos el stunnel para enviar el redis a localhost usando la siguiente configuración de stunnel.

fips = no

setuid = raíz

setgid = raíz

pid = /var/run/stunnel.pid
depurar = 7

opciones = NO_SSLv2

opciones = NO_SSLv3
salida = /var/log/stunnel.log

cliente = no

primer plano = sí

[redis-cli]
cliente = si
aceptar = 127.0.0.1:6379
connect = redi punto de envío: 6379

El nodo se desconecta con los siguientes errores cada dos minutos. Los ejecutamos a través de contenedores Docker.

La conexión de Redis a 127.0.0.1:6379 falló - lea ECONNRESET
en TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
Error: la conexión de Redis a 127.0.0.1:6379 falló - lea ECONNRESET
en TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
Error: la conexión de Redis a 127.0.0.1:6379 falló - lea ECONNRESET
en TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
AbortError: Se perdió la conexión de Redis y se canceló el comando. Podría haber sido procesado.

alguna resolución?

También nos enfrentamos al mismo problema, pero aquí colocamos el stunnel para enviar el redis a localhost usando la siguiente configuración de stunnel.

fips = no

setuid = raíz

setgid = raíz

pid = /var/run/stunnel.pid
depurar = 7

opciones = NO_SSLv2

opciones = NO_SSLv3
salida = /var/log/stunnel.log

cliente = no

primer plano = sí

[redis-cli]
cliente = si
aceptar = 127.0.0.1:6379
connect = redi punto de envío: 6379

El nodo se desconecta con los siguientes errores cada dos minutos. Los ejecutamos a través de contenedores Docker.

La conexión de Redis a 127.0.0.1:6379 falló - lea ECONNRESET
en TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
Error: la conexión de Redis a 127.0.0.1:6379 falló - lea ECONNRESET
en TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
Error: la conexión de Redis a 127.0.0.1:6379 falló - lea ECONNRESET
en TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
AbortError: Se perdió la conexión de Redis y se canceló el comando. Podría haber sido procesado.

alguna resolución?

Lo mismo para mí, creo que esto es un problema con el aturdimiento.

También estoy enfrentando el mismo error

{ Error: Redis connection to xx.xx.x.x:6379 failed - read ECONNRESET" 

at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' 

También estoy usando el controlador de errores, pero la cuestión es por qué sucede esto, puede afectar mis llamadas de consulta y retrasar mis solicitudes.

@Ayaz ¿Puede abrir este problema porque este problema no está completamente resuelto? La gente solo ha manejado la respuesta de error, pero el problema aún no está resuelto.

Golpes: el mismo problema aquí:

error: Error: Redis connection to xx.yy.zz.aa:6379 failed - read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:205:27) { errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' },

Veo lo mismo en problema con:

• NodeJS v12.16.3
• Marco NestJS
• IOredis: 4.2
• nestjs-redis: 1.2.8

Redis se proporciona mediante Google Cloud MemoryStore.

Los registros muestran:

[ioredis] Evento de error no controlado: Error: leer ECONNRESET

Esto sucede aproximadamente una vez cada 24 horas sin ningún motivo específico o los mismos pasos, simplemente sucede

@ robertop87
Veo el mismo problema. Redis se proporciona mediante Google Cloud MemoryStore. ¿Resolviste este problema?

También veo un problema muy similar con Cloud run / Cloud Functions al conectarse a Cloud Memory Store. Posiblemente podría estar sucediendo cuando Google detiene los recursos subyacentes de forma aleatoria demasiado pronto.

Este problema comenzó hace aproximadamente una semana para nosotros, sin cambios en la forma en que manejamos la conexión de Redis. También estamos usando ioredis para manejar la conexión y ejecutar el nodo 12.

IORedis tiene como estrategia predeterminada volver a conectarse en caso de error, pero por alguna razón no está sucediendo.

Lo que hice fue agregar lo siguiente en la configuración:

reconnectOnError: (error): boolean => {
  console.log('Always reconnect on error', error)
  return true
}

El error ECONNRESET sigue presente, pero ahora se reintenta mi conexión y mi instancia de Google ya no se bloquea.

CC: @ hkd987

Lea más detalles sobre reconnectOnError aquí: https://github.com/luin/ioredis

@ robertop87 Hizo una nueva implementación con la configuración específica para siempre reconnectOnError establecido para devolver verdadero. Esto parece un problema que debe reabrirse o se debe hacer un nuevo ticket, ya que esto está sucediendo en la última versión.