Für mich klingt dies nach einem Netzwerkproblem außerhalb von Node.js. Dieser Fehler "ECONNRESET" tritt auf, wenn die Remoteverbindung zu Node.js den Socket unerwartet schließt.

Verwenden Sie einen Proxy zwischen Node und Redis?

Welche Version des Node / Node_redis / Redis-Servers?

Ich bezweifle, dass der NewRelic-Agent beteiligt ist, aber Sie können jederzeit versuchen, ohne den Agenten zu reproduzieren, um festzustellen, ob das Problem dadurch behoben wird. cc / @wraithan

Diese Zeilen sind nur CLS, die das tun. Mit mehr Repro könnte ich den New Relic-Agenten vollständig ausschließen. Aber ich bin relativ zuversichtlich, dass dies nicht von uns verursacht wird.

Ich habe den NewRelic-Agenten entfernt. Das Problem tritt weiterhin auf. Ca. Alle 3 Minuten passiert dieser Absturz. Unten finden Sie die Protokolle als Referenz.

events.js: 72
werfen äh; // Nicht behandeltes 'Fehler'-Ereignis
^
Fehler: Verbindung zu redis1.tfs wird wiederhergestellt. tfs: 6379 fehlgeschlagen - ECONNRESET lesen
bei RedisClient.on_error (/var/www/a/b/c/node_modules/redis/index.js:196:24)
bei Socket.(/var/www/a/b/c/node_modules/redis/index.js:106:14)
bei Socket.emit (events.js: 95: 17)
at net.js: 441: 14
at process._tickDomainCallback (node.js: 486: 13)
Fehler: Für immer erkanntes Skript mit Code beendet: 8
Fehler: Skript-Neustartversuch Nr. 50

Außerdem verwende ich Node.JS - v0.10.35, node_redis - 0.12.1 & Redis - 2.8.4.
Ich greife direkt über IP in Node auf Redis zu.

Ich war auch mit diesem Problem konfrontiert, wurde aber erst gelöst, als mir klar wurde, dass ich gestern aus einem anderen Grund mit meiner /etc/hosts -Datei herumgespielt habe. Es fehlte:

127.0.0.1 localhost

@ ayazpasha2434 Die Lösung ist möglicherweise nicht dieselbe für Sie, aber wie andere andeuten, befindet sie sich definitiv außerhalb des Knotens und in env / shell / OS / VM. Treten Sie ein wenig zurück und starren Sie es an.

@sarathms Ich habe diese Zuordnung in meiner Hosts-Datei. In meinem Fall handelt es sich jedoch um eine Remote-Maschine. Nur abgeglichen, ich habe das besagte Localhost-Mapping auch in der Redis-Maschine. Das Problem ist immer noch nicht gelöst.

Ich stehe auch vor dem gleichen Problem. Hier ist die Konsolenausgabe

events.js: 72
werfen äh; // Nicht behandeltes 'Fehler'-Ereignis
^
Fehler: Redis-Verbindung zu pub-redis-10606.us-east-1-1.1.ec2.garantiadata. com: 10606 fehlgeschlagen - ECONNRESET unter RedisClient.on_error lesen (C: UsersGigiDesktopeduknow_api_ver_1authnode_m
odulesredisindex.js: 196: 24)
bei Socket.(C: UsersGigiDesktopeduknow_api_ver_1authnode_modulesredisindex.js: 106: 14)
bei Socket.emit (events.js: 95: 17)
at net.js: 441: 14
at process._tickCallback (node.js: 442: 13)

@ ayazpasha2434 Diese Zeile hat meinen Fehler behoben

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

@ ayazpasha2434 Hatte @Waterloo die richtige Antwort für Sie?

Es schien ein Problem mit Ihrer Netzwerkverbindung zu geben, und es scheint kein Problem mit Node Redis zu geben. Das Hinzufügen der Fehlerbehandlungsroutine sollte ausreichen, damit die App nicht mehr abstürzt (und immer angehängt wird).

Ich bin auf dieses Problem gestoßen, als ich ein http (use post) auf dem JAVA-Server poste. {[Fehler: ECONNRESET lesen]
Code: 'ECONNRESET',
errno: 'ECONNRESET',
syscall: 'lesen',
Antwort: undefiniert}
Fehler: ECONNRESET lesen
at exports._errnoException (util.js: 856: 11)
bei TCP.onread (net.js: 546: 26)
doppelter Rückruf!
POST / user_archives / create / save 500 45.306 ms - 386
Fehler: ECONNRESET lesen
at exports._errnoException (util.js: 856: 11)
bei TCP.onread (net.js: 546: 26)

@ biggu0 Ich bin mir nicht sicher, welche Verbindung dies zu node_redis hat. Um mehr über ECONNRESET zu erfahren, Stackoverflow ansehen .

Hallo ,
Wir sehen auch dieses Problem. Wir beobachten, dass es an Redis SNAPSHOTTING liegen könnte. Immer wenn redis einen Schnappschuss macht und das Speichern auf der Festplattenverbindung zurückgesetzt wird. Um mich zu beweisen, vergleiche ich die Anwendungsprotokolle mit den Redis-Debug-Protokollen und die Timings stimmen genau überein.

Unten finden Sie die Snapshot-Einstellung in redis.conf
900 sparen 1
300 sparen 10
60 10000 sparen

Bitte lassen Sie uns wissen, wenn wir etwas falsch machen.

Ich bin auch häufig mit Verbindungsproblemen konfrontiert.

ERR bei RedisClient.emit (events.js: 188: 7)
ERR bei RedisClient.on_error (/home/vcap/app/node_modules/redis/index.js:394:14)
ERR bei RedisClient.(/home/vcap/app/server.js:28:13)
ERR bei emitErrorNT (net.js: 1281: 8)
ERR bei Socket.(/home/vcap/app/node_modules/redis/index.js:272:14)
ERR bei process._tickCallback (intern / process / next_tick.js: 98: 9)
ERR-Fehler: Redis-Verbindung zu XXXXXXXX: XXXXX fehlgeschlagen - ECONNRESET lesen
ERR bei TCP.onread (net.js: 572: 26)
ERR bei _combinedTickCallback (intern / process / next_tick.js: 74: 11)
ERR bei emitOne (events.js: 96: 13)
ERR bei exports._errnoException (util.js: 1022: 11)
ERR bei Socket.emit (events.js: 188: 7)

Nachdem der Fehler aufgetreten ist, wird die Verbindung automatisch wiederhergestellt.
Was kann das Problem sein, um die Verbindung zu verlieren.

Hallo Waterloo,
Wo Sie diese Anweisung setzen client.on ('error', function (err) {console.error (err)})
und ich denke diese Aussage nur zur Konsole deines Fehlers sonst nichts.
ist es wirklich brauchbar?
Bitte geben Sie mir Ihre Gedanken so schnell wie möglich.

Danke im Voraus!!!

Hallo

Ich stehe auch vor dem gleichen Problem

events.js: 160
werfen äh; // Nicht behandeltes 'Fehler'-Ereignis
^

Fehler: ECONNRESET lesen

Dies löste mein Problem mit:

1. Ich habe alle meine Prozessüberwachung deaktiviert (neues Relikt, elastische apm ...)
2. Ich habe diesen Code verwendet
   `` `Javascript
   process.on ('uncaughtException', function (err) {
   console.error (err.stack);
   console.log ("Knoten wird NICHT beendet ...");
   });

Ich bin auch mit diesem Problem konfrontiert. Ich verwende das Sails.js-Framework mit einem Hook, sodass beim Starten des Knotendienstes nur eine Verbindung zum Redis-Server besteht. Wir verwenden das globale Sail-Objekt, um auf Redis zuzugreifen und mit ihm zu arbeiten

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);
    }
});

Hier ist die Stapelverfolgung des Fehlers
AbortError: Die Verbindung wird erneut unterbrochen und der Befehl abgebrochen. Möglicherweise wurde es unter RedisClient.flush_and_error (/var/sample-app/node_modules/redis/index.js:362:23)n unter RedisClient.connection_gone (/ var / sample-app / node_modules / redis / index) verarbeitet. js: 664: 14) n bei RedisClient.on_error (/var/sample-app/node_modules/redis/index.js:410:10)n bei Socket.(/var/sample-app/node_modules/redis/index.js:279:14)n bei emitOne (events.js: 116: 13) n bei Socket.emit (events.js: 211: 7) n bei emitErrorNT ( intern / stream / destroy.js: 66: 8) n unter /var/sample-app/node_modules/async-listener/glue.js:188:31n unter args. (anonyme Funktion) (/ usr / lib / node_modules / pm2) /node_modules/event-loop-inspector/index.js:138:29)n bei _combinedTickCallback (intern / process / next_tick.js: 139: 11) n bei process._tickDomainCallback (intern / process / next_tick.js: 219: 9 ) n at process.fallback (/var/sample-app/node_modules/async-listener/index.js:563:15).

Unsere Node-App wird auf einem Docker-Container ausgeführt und stellt eine Verbindung zum Redis-Server her, der auf einer EC2-Linux-Instanz installiert ist.

Wir haben auch das gleiche Problem, aber hier haben wir den Stunnel platziert, um die Redis unter Verwendung der folgenden Stunnel-Konfiguration an localhost zu übertragen.

fips = nein

setuid = root

setgid = root

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

options = NO_SSLv2

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

client = no

Vordergrund = ja

[redis-cli]
client = ja
accept = 127.0.0.1:6379
connect = redi sendpoint: 6379

Der Knoten trennt die Verbindung mit den folgenden Fehlern alle paar Minuten. Wir führen diese durch Docker-Container.

Redis-Verbindung zu 127.0.0.1:6379 fehlgeschlagen - ECONNRESET lesen
bei TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
Fehler: Redis-Verbindung zu 127.0.0.1:6379 fehlgeschlagen - ECONNRESET lesen
bei TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
Fehler: Redis-Verbindung zu 127.0.0.1:6379 ist fehlgeschlagen - ECONNRESET lesen
bei TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
AbortError: Die Verbindung wird erneut unterbrochen und der Befehl abgebrochen. Es könnte verarbeitet worden sein.

irgendeine Auflösung?

Wir haben auch das gleiche Problem, aber hier haben wir den Stunnel platziert, um die Redis unter Verwendung der folgenden Stunnel-Konfiguration an localhost zu übertragen.

fips = nein

setuid = root

setgid = root

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

options = NO_SSLv2

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

client = no

Vordergrund = ja

[redis-cli]
client = ja
accept = 127.0.0.1:6379
connect = redi sendpoint: 6379

Der Knoten trennt die Verbindung mit den folgenden Fehlern alle paar Minuten. Wir führen diese durch Docker-Container.

Redis-Verbindung zu 127.0.0.1:6379 fehlgeschlagen - ECONNRESET lesen
bei TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
Fehler: Redis-Verbindung zu 127.0.0.1:6379 ist fehlgeschlagen - ECONNRESET lesen
bei TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
Fehler: Redis-Verbindung zu 127.0.0.1:6379 ist fehlgeschlagen - ECONNRESET lesen
bei TCP.onStreamRead (internal / stream_base_commons.js: 111: 27)
AbortError: Die Verbindung wird erneut unterbrochen und der Befehl abgebrochen. Es könnte verarbeitet worden sein.

irgendeine Auflösung?

Ich denke, das ist ein Problem mit Stunnel

Ich stehe auch vor dem gleichen Fehler

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

Ich verwende auch eine Fehlerbehandlungsroutine, aber die Ursache ist, warum dies geschieht. Dies kann sich auf meine Abfrageaufrufe auswirken und meine Anforderungen verzögern.

@Ayaz Können Sie dieses Problem bitte öffnen, da dieses Problem nicht vollständig behoben ist

Bumping: Gleiches Problem hier:

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

Ich sehe das gleiche Problem mit:

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

Redis wird mithilfe des Google Cloud MemoryStore bereitgestellt.

Das Protokoll zeigt:

[ioredis] Nicht behandeltes Fehlerereignis: Fehler: ECONNRESET lesen

Dies geschieht ungefähr alle 24 Stunden einmal ohne einen bestimmten Grund oder dieselben Schritte, es passiert einfach

@ robertop87
Ich sehe das gleiche Problem. Redis wird mithilfe des Google Cloud MemoryStore bereitgestellt. Haben Sie dieses Problem behoben?

Auch beim Herstellen einer Verbindung zum Cloud Memory Store tritt ein sehr ähnliches Problem mit Cloud-Lauf- / Cloud-Funktionen auf. Es kann vorkommen, dass die zugrunde liegenden Ressourcen von Google zu früh zufällig gestoppt werden.

Dieses Problem hat vor ungefähr einer Woche für uns begonnen, ohne dass Änderungen am Umgang mit der Redis-Verbindung vorgenommen wurden. Wir verwenden ioredis auch, um die Verbindung zu handhaben und Knoten 12 auszuführen.

IORedis hat als Standardstrategie eine erneute Verbindung bei Fehlern, aber aus irgendeinem Grund geschieht dies nicht.

Was ich getan habe, ist das nächste in der Konfiguration hinzuzufügen:

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

Der ECONNRESET-Fehler ist weiterhin vorhanden, aber jetzt wird meine Verbindung erneut versucht und meine Google-Instanz bleibt nicht mehr hängen.

CC: @ hkd987

Weitere Informationen zu reconnectOnError hier: https://github.com/luin/ioredis

@ robertop87 Es wurde eine neue Bereitstellung mit der spezifischen Konfiguration erstellt, bei der immer reconnectOnError auf true zurückgegeben wird. Dies scheint ein Problem zu sein, das erneut geöffnet oder ein neues Ticket erstellt werden muss, da dies in der neuesten Version geschieht.