Node-redis: Redis-Client mit Optionsobjekt ohne Host und Port erstellen.

Erstellt am 16. März 2019  ·  18Kommentare  ·  Quelle: NodeRedis/node-redis

Dieser Code wird ohne Fehler ausgeführt, auch wenn kein lokaler Server ausgeführt wird. Ist es das richtige Verhalten oder ein Bug?

const redis = require('redis')
const redisClient = redis.createClient({ retry_strategy: () => 1000 })
  • Version : 2.8.
  • Plattform : Node.js 10.15.3 Mac OS X Mojave, Node.js 11 alpine, Node.js 10.15.3 alpine
  • Beschreibung : Redis-Client mit Optionsobjekt ohne Host und Port erstellen.
Evaluating

Alle 18 Kommentare

@mikhailsidorov - Ja, das ist richtig, da die Standardoptionen 'localhost' bzw. 6379 sind.

Oh, aber Sie sagen, dass kein lokaler Redis-Server läuft? hahaha
Das wäre jetzt unglaublich seltsam.

Ich garantiere Ihnen, dass Sie immer noch eine Redis-Instanz ausführen ... gehen Sie zu Ihrer Linux-Befehlszeilenkonsole.

Alle laufenden Instanzen von Redis anzeigen
ps -aux | grep redis-server

Töte alle Redis-Instanzen
killall redis-server

Ticket schließen?

Ich habe es im Docker ausgeführt, ohne Redis. Lassen Sie mich noch einmal überprüfen.

Redis muss irgendwo laufen, ich habe es in meiner Umgebung ausprobiert und /etc/init.d/redis-server stop . Das erste Mal tat es genau so, wie Sie es erwähnt haben, als ich verblüfft war! Dann habe ich ps -aux | grep redis-server herausgefunden, dass sieben Redis-Instanzen im Hintergrund laufen, lol. Nachdem alle gelöscht wurden, wurde die Knotenwiederholung sofort wie erwartet fehlgeschlagen.

@mikhailsidorov - Ja, das ist richtig, da die Standardoptionen 'localhost' bzw. 6379 sind.

Oh, aber Sie sagen, dass kein lokaler Redis-Server läuft? hahaha
Das wäre jetzt unglaublich seltsam.

Ich garantiere Ihnen, dass Sie immer noch eine Redis-Instanz ausführen ... gehen Sie zu Ihrer Linux-Befehlszeilenkonsole.

Alle laufenden Instanzen von Redis anzeigen
ps -aux | grep redis-server

Töte alle Redis-Instanzen
killall redis-server

Ticket schließen?

Auf meinem Computer und im Docker-Container gibt es keine Redis-Server-Prozesse. Außerdem habe ich keinen Prozess, der 6379-Port abhört ( netstat -an | grep 6379 nichts zurück).

Redis muss irgendwo laufen, ich habe es in meiner Umgebung ausprobiert und /etc/init.d/redis-server stop . Das erste Mal tat es genau so, wie Sie es erwähnt haben, als ich verblüfft war! Dann habe ich ps -aux | grep redis-server herausgefunden, dass sieben Redis-Instanzen im Hintergrund laufen, lol. Nachdem alle gelöscht wurden, wurde die Knotenwiederholung sofort wie erwartet fehlgeschlagen.

Ich habe keinen Prozess des Redis-Servers gefunden.

Ich habe ein Beispiel für die Reproduktion des Problems vorbereitet, siehe dieses Repo https://github.com/mikhailsidorov/redis-issue
Dieser Code läuft ohne Fehler, und ich habe keine Redis-Server-Prozesse auf dem getesteten Computer und dem Docker-Container ausgeführt.

Läufst du zufällig Redis-Mock oder ähnliches? (Bezweifle es, ich prüfe nur...)
https://github.com/faeldt/redis-mock

Hier ist die Fehlermeldung, die ich erhalte, wenn ich Redis deaktiviere und meine App ausführe ... (Dies ist nicht die von Ihnen bereitgestellte Docker-App) Ich muss Docker einrichten, ich verwende Docker immer noch nicht, ich muss mit der Zeit gehen. Werde es später mal versuchen....

Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1054:14)
Emitted 'error' event at:
    at RedisClient.on_error (/mnt/c/indospace.io/services/node_modules/redis/index.js:406:14)
    at Socket.<anonymous> (/mnt/c/indospace.io/services/node_modules/redis/index.js:279:14)
    at Socket.emit (events.js:196:13)
    at emitErrorNT (internal/streams/destroy.js:91:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:17)

Läufst du zufällig Redis-Mock oder ähnliches? (Bezweifle es, ich prüfe nur...)
https://github.com/faeldt/redis-mock

Hier ist die Fehlermeldung, die ich erhalte, wenn ich Redis deaktiviere und meine App ausführe ... (Dies ist nicht die von Ihnen bereitgestellte Docker-App) Ich muss Docker einrichten, ich verwende Docker immer noch nicht, ich muss mit der Zeit gehen. Werde es später mal versuchen....

Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED 127.0.0.1:6379
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1054:14)
Emitted 'error' event at:
    at RedisClient.on_error (/mnt/c/indospace.io/services/node_modules/redis/index.js:406:14)
    at Socket.<anonymous> (/mnt/c/indospace.io/services/node_modules/redis/index.js:279:14)
    at Socket.emit (events.js:196:13)
    at emitErrorNT (internal/streams/destroy.js:91:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:17)

Nein, ich benutze kein Redis-Mock. Wenn ich const redisClient = redis.createClient() ohne Optionen ausführe, erhalte ich den gleichen Fehler, aber wenn ich { retry_strategy: () => 1000 } bekomme ich dieses Problem.

oh okay, denke wir sind jetzt auf der gleichen Seite...

Ja, der Code für die erneute Verbindung/Wiederverbindung von node_redis scheint im Moment völlig kaputt zu sein, es gibt zahlreiche offene Tickets, die sich auf diese Probleme beziehen. Ich habe heute Abend PR-Anfragen zu anderen nodeJS-Modulen erhalten, werde versuchen, mich damit zu befassen und eine gültige PR einzureichen, wenn ich kann.

oh okay, denke wir sind jetzt auf der gleichen Seite...

Ja, der Code für die erneute Verbindung/Wiederverbindung von node_redis scheint im Moment völlig kaputt zu sein, es gibt zahlreiche offene Tickets, die sich auf diese Probleme beziehen. Ich habe heute Abend PR-Anfragen zu anderen nodeJS-Modulen erhalten, werde versuchen, mich damit zu befassen und eine gültige PR einzureichen, wenn ich kann.

Dankeschön

Dies ist etwas beabsichtigt. Überprüfen Sie connect_timeout : Default is to try connecting until the default system socket timeout has been exceeded and to try reconnecting until 1h has elapsed. .

Die Absicht ist, eine sehr leistungsfähige Funktion zu haben, bei der die gesamte Wiederverbindungslogik in den Händen des Benutzers liegt. Es kann jedoch nicht immer ideal sein.

Dies ist etwas beabsichtigt. Überprüfen Sie connect_timeout : Default is to try connecting until the default system socket timeout has been exceeded and to try reconnecting until 1h has elapsed. .

Die Absicht ist, eine sehr leistungsfähige Funktion zu haben, bei der die gesamte Wiederverbindungslogik in den Händen des Benutzers liegt. Es kann jedoch nicht immer ideal sein.

Danke für die Abklärung.

@mikhailsidorov - Problem schließen?

@knoxcard Ich möchte dies für mich offen halten, um mir das noch einmal anzusehen, wenn ich etwas Zeit finde.

@knoxcard danke, dass hast ! Haben Sie Interesse, allgemein mehr zu helfen?

@BridgeAR - absolut! Wie soll ich mehr helfen?

@mikhailsidorov - Problem schließen?

Klar, wenn es nötig ist. Vielen Dank

@mikhailsidorov - vergiss es, das Problem zu schließen, BridgeAr möchte dieses Problem offen halten, Danke!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen