Pour moi, cela ressemble à un problème de réseau en dehors de Node.js, cette erreur "ECONNRESET" se produit lorsque la connexion à distance à Node.js ferme le socket de manière inattendue.

Utilisez-vous un proxy entre Node et Redis?

Quelle version du serveur Node / node_redis / Redis?

Je doute que l'agent NewRelic soit impliqué, mais vous pouvez toujours essayer de reproduire sans l'agent et voir si cela résout le problème. cc / @wraithan

Ces lignes sont juste CLS qui fait son truc. Avec plus d'un repro, je pourrais totalement exclure l'agent New Relic. Mais je suis relativement convaincu que cela n'est pas causé par nous.

J'ai supprimé l'agent NewRelic, le problème persiste. Environ. toutes les 3 minutes, je reçois ce crash. Voici les journaux pour référence.

events.js: 72
lanceur; // Evénement "erreur" non géré
^
Erreur: connexion Redis à redis1.tfs. tfs: 6379 a échoué - lire ECONNRESET
à RedisClient.on_error (/var/www/a/b/c/node_modules/redis/index.js:196:24)
à Socket.(/var/www/a/b/c/node_modules/redis/index.js:106:14)
à Socket.emit (events.js: 95: 17)
sur net.js: 441: 14
à process._tickDomainCallback (node.js: 486: 13)
erreur: script détecté pour toujours sorti avec le code: 8
erreur: tentative de redémarrage du script # 50

De plus, j'utilise Node.JS - v0.10.35, node_redis - 0.12.1 & Redis - 2.8.4.
J'accède à Redis directement via IP dans Node.

J'étais confronté à ce problème aussi, mais je viens d'être résolu après avoir réalisé que je jouais hier avec mon fichier /etc/hosts pour une autre raison. Il manquait:

127.0.0.1 localhost

@ ayazpasha2434, la solution n'est peut-être pas la même pour vous, mais comme d'autres le suggèrent, elle est définitivement en dehors du nœud et dans l'environnement env / shell / OS / VM. Reculez un peu et regardez-le.

@sarathms J'ai ce mappage dans mon fichier d'hôtes. Cependant, la machine Redis dans mon cas est une machine distante. Juste contre-vérifié, j'ai également le mappage de l'hôte local dans la machine Redis. Le problème n'est toujours pas résolu.

Je suis également confronté au même problème . Voici la sortie de la console

events.js: 72
lanceur; // Evénement "erreur" non géré
^
Erreur: connexion Redis à pub-redis-10606.us-east-1-1.1.ec2.garantiadata. com: 10606 a échoué - lire ECONNRESET sur RedisClient.on_error (C: UsersGigiDesktopeduknow_api_ver_1authnode_m
odulesredisindex.js: 196: 24)
à Socket.(C: UsersGigiDesktopeduknow_api_ver_1authnode_modulesredisindex.js: 106: 14)
à Socket.emit (events.js: 95: 17)
sur net.js: 441: 14
à process._tickCallback (node.js: 442: 13)

@ ayazpasha2434 Cette ligne a résolu mon erreur

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

@ ayazpasha2434 @Waterloo avait-il la bonne réponse pour vous?

Il semble y avoir un problème avec votre connexion réseau et cela ne semble pas être un problème avec le nœud redis. L'ajout du gestionnaire d'erreurs devrait être suffisant pour que l'application ne plante plus (et elle devrait toujours être attachée).

J'ai rencontré ce problème lorsque je poste un http (utiliser un post) sur le serveur JAVA. {[Erreur: read ECONNRESET]
code: 'ECONNRESET',
errno: 'ECONNRESET',
syscall: 'lire',
réponse: undefined}
Erreur: lire ECONNRESET
à exports._errnoException (util.js: 856: 11)
sur TCP.onread (net.js: 546: 26)
double rappel!
POST / user_archives / create / save 500 45,306 ms - 386
Erreur: lire ECONNRESET
à exports._errnoException (util.js: 856: 11)
sur TCP.onread (net.js: 546: 26)

@ biggu0 Je ne sais pas quelle connexion cela a à node_redis. Pour en savoir plus sur ECONNRESET, vous pouvez consulter stackoverflow .

Salut ,
Nous constatons également ce problème. Nous observons que cela pourrait être à cause de redis SNAPSHOTTING. Chaque fois que Redis prend un instantané et le stockage sur le disque, la connexion est réinitialisée. Pour me prouver, je compare les journaux d'application avec les journaux de débogage Redis et les horaires correspondent exactement.

ci-dessous sont le paramètre de capture instantanée dans redis.conf
enregistrer 900 1
sauver 300 10
économisez 60 10000

S'il vous plaît laissez-nous savoir si nous faisons quelque chose de mal.

Je suis également confronté fréquemment à des problèmes de connexion.

ERR sur RedisClient.emit (events.js: 188: 7)
ERR à RedisClient.on_error (/home/vcap/app/node_modules/redis/index.js:394:14)
ERR chez RedisClient.(/home/vcap/app/server.js:28:13)
ERR à emitErrorNT (net.js: 1281: 8)
ERR à Socket.(/home/vcap/app/node_modules/redis/index.js:272:14)
ERR à process._tickCallback (interne / process / next_tick.js: 98: 9)
Erreur ERR: connexion Redis à XXXXXXXX: échec de
ERR à TCP.onread (net.js: 572: 26)
ERR à _combinedTickCallback (interne / process / next_tick.js: 74: 11)
ERR à emitOne (events.js: 96: 13)
ERR à exports._errnoException (util.js: 1022: 11)
ERR sur Socket.emit (events.js: 188: 7)

Après avoir obtenu l'erreur, il se reconnecte automatiquement.
Quel peut être le problème de perdre la connexion.

Salut Waterloo,
Où vous mettez cette instruction client.on ('error', function (err) {console.error (err)})
et je pense que cette déclaration juste pour la console de votre erreur rien d'autre.
est-ce vraiment utilisable?
Veuillez me donner votre avis dès que possible.

Merci d'avance!!!

Bonjour

Je suis également confronté au même problème

events.js: 160
lanceur; // Evénement "erreur" non géré
^

Erreur: lire ECONNRESET

Cela a résolu mon problème avec:

1. J'ai désactivé tous mes processus de surveillance (nouvelle relique, apm élastique ...)
2. J'ai utilisé ce code
   `` Javascript
   process.on ('uncaughtException', fonction (err) {
   console.error (err.stack);
   console.log ("Nœud PAS en cours de sortie ...");
   });

Je suis également confronté à ce problème. J'utilise avec le framework sails.js avec un crochet, il n'y a donc qu'une seule connexion au serveur redis lors du démarrage du service de nœud, nous utiliserons l'objet global sails pour accéder et travailler avec 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);
    }
});

Voici la trace de la pile de l'erreur
AbortError: connexion Redis perdue et commande abandonnée. Il peut avoir été traité.n à RedisClient.flush_and_error (/var/sample-app/node_modules/redis/index.js:362:23)n à RedisClient.connection_gone (/ var / sample-app / node_modules / redis / index. js: 664: 14) n sur RedisClient.on_error (/var/sample-app/node_modules/redis/index.js:410:10)n sur Socket.(/var/sample-app/node_modules/redis/index.js:279:14) n à emitOne (events.js: 116: 13) n à Socket.emit (events.js: 211: 7) n à emitErrorNT ( internal / streams / destroy.js: 66: 8) n at /var/sample-app/node_modules/async-listener/glue.js:188:31n at args. (fonction anonyme) (/ usr / lib / node_modules / pm2 /node_modules/event-loop-inspector/index.js:138:29)n à _combinedTickCallback (interne / process / next_tick.js: 139: 11) n à process._tickDomainCallback (interne / process / next_tick.js: 219: 9 ) n sur process.fallback (/var/sample-app/node_modules/async-listener/index.js:563:15).

Notre application de nœud s'exécute sur un conteneur Docker et se connectera au serveur Redis installé sur une instance Linux EC2.

Nous sommes également confrontés au même problème, mais ici nous avons placé le stunnel pour proxy le redis vers localhost en utilisant la configuration stunnel ci-dessous.

fips = non

setuid = racine

setgid = racine

pid = /var/run/stunnel.pid
débogage = 7

options = NO_SSLv2

options = NO_SSLv3
sortie = /var/log/stunnel.log

client = non

premier plan = oui

[redis-cli]
client = oui
accepter = 127.0.0.1:6379
connect = point d'envoi redi: 6379

Le nœud se déconnecte avec ces erreurs ci-dessous toutes les deux minutes. Nous les exécutons via des conteneurs docker.

La connexion Redis à 127.0.0.1:6379 a échoué - lecture ECONNRESET
à TCP.onStreamRead (interne / stream_base_commons.js: 111: 27)
Erreur: la connexion Redis à 127.0.0.1:6379 a échoué - lecture ECONNRESET
à TCP.onStreamRead (interne / stream_base_commons.js: 111: 27)
Erreur: la connexion Redis à 127.0.0.1:6379 a échoué - lecture ECONNRESET
à TCP.onStreamRead (interne / stream_base_commons.js: 111: 27)
AbortError: connexion Redis perdue et commande abandonnée. Cela aurait pu être traité.

une résolution?

Nous sommes également confrontés au même problème, mais ici nous avons placé le stunnel pour proxy le redis vers localhost en utilisant la configuration stunnel ci-dessous.

fips = non

setuid = racine

setgid = racine

pid = /var/run/stunnel.pid
débogage = 7

options = NO_SSLv2

options = NO_SSLv3
sortie = /var/log/stunnel.log

client = non

premier plan = oui

[redis-cli]
client = oui
accepter = 127.0.0.1:6379
connect = point d'envoi redi: 6379

Le nœud se déconnecte avec ces erreurs ci-dessous toutes les deux minutes. Nous les exécutons via des conteneurs docker.

La connexion Redis à 127.0.0.1:6379 a échoué - lecture ECONNRESET
à TCP.onStreamRead (interne / stream_base_commons.js: 111: 27)
Erreur: la connexion Redis à 127.0.0.1:6379 a échoué - lecture ECONNRESET
à TCP.onStreamRead (interne / stream_base_commons.js: 111: 27)
Erreur: la connexion Redis à 127.0.0.1:6379 a échoué - lecture ECONNRESET
à TCP.onStreamRead (interne / stream_base_commons.js: 111: 27)
AbortError: connexion Redis perdue et commande abandonnée. Cela aurait pu être traité.

une résolution?

pareil pour moi, je pense que c'est un problème avec stunnel

Je suis également confronté à la même erreur

{ 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' 

J'utilise également un gestionnaire d'erreurs, mais le problème est de savoir pourquoi cela se produit, cela peut avoir un impact sur mes appels de requête et retarder mes requêtes.

@Ayaz Pouvez-vous s'il vous plaît ouvrir ce problème car ce problème n'est pas complètement résolu les gens ont seulement géré la réponse d'erreur mais le problème n'est toujours pas résolu.

Bumping: même problème ici:

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' },

Je vois la même chose avec:

• NodeJS v12.16.3
• Cadre NestJS
• IOredis: 4,2
• nestjs-redis: 1.2.8

Redis est fourni à l'aide de Google Cloud MemoryStore.

Les journaux montrent:

[ioredis] Événement d'erreur non géré: Erreur: lecture ECONNRESET

Cela se produit environ une fois toutes les 24 heures sans raison spécifique ni mêmes étapes, cela arrive

@ robertop87
Je vois le même problème. Redis est fourni à l'aide de Google Cloud MemoryStore. As-tu résolu ce problème?

Voir également un problème très similaire avec Cloud run / Cloud Functions lors de la connexion à Cloud Memory Store. Cela pourrait se produire lorsque les ressources sous-jacentes sont arrêtées trop tôt au hasard par Google.

Ce problème a commencé il y a environ une semaine pour nous, sans changement dans la façon dont nous gérons la connexion Redis. Nous utilisons également ioredis pour gérer la connexion et exécuter le nœud 12.

IORedis a comme stratégie par défaut la reconnexion en cas d'erreur, mais pour une raison quelconque, cela ne se produit pas.

Ce que j'ai fait est d'ajouter le suivant dans la configuration:

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

L'erreur ECONNRESET est toujours présente, mais ma connexion est maintenant réessayée et mon instance Google n'est plus bloquée.

CC: @ hkd987

Lisez plus de détails sur reconnectOnError ici: https://github.com/luin/ioredis

@ robertop87 A fait un nouveau déploiement avec la configuration spécifique pour toujours reconnectOnError définie pour retourner true. Cela semble être un problème qui doit être rouvert ou un nouveau ticket créé, car cela se produit sur la dernière version.