Node-redis: Les abonnements ne reçoivent pas de données après la reconnexion
node_redis : 2.7.1
redis : 3,2
plateforme : Amazon linux
la description:
Lorsque l'instantané de Redis se produit, il déconnecte le client Redis. Le client se reconnecte et se réabonne, mais il ne reçoit plus de données. Ceci peut être reproduit en émettant une commande SAVE via le redis-cli.
JS
const redis = require('redis');
const redisClient = redis.createClient({
host: config.redisEndpoint,
port: config.redisPort,
});
redisClient.on('connect', () => {
console.log('Connected to Redis');
console.log('subscription_set:', redisClient.subscription_set);
});
redisClient.on('reconnecting', (stats) => {
console.log('Reconnecting to Redis', stats);
});
redisClient.on('error', (error) => {
console.log('Failed to connect to Redis: ', error);
});
redisClient.on('subscribe', (channel, count) => { // eslint-disable-line no-unused-vars
console.log('Subscribed to: ', channel, count);
});
redisClient.on('message', (channel, message) => { // eslint-disable-line no-unused-vars
console.log('Received from: ', channel, message);
});
redisClient.subscribe('test');
Journaux
Connexion initiale
info: Connected to Redis
info: subscription_set:
info: Subscribed to: test 1
Émettre une commande SAVE dans redis-cli
info: Error: Redis connection to 34.213.3.19:6379 failed - read ECONNRESET
info: Reconnecting to Redis delay=983, attempt=4, code=ECONNRESET, errno=ECONNRESET, syscall=connect, address=127.0.0.1, port=6379, total_retry_time=1118, times_connected=1
info: Connected to Redis
info: subscription_set: subscribe_test=test
info: Subscribed to: test 1
C'est à ce stade que le client ne recevra plus aucune donnée publiée sur le test de canal. Si vous avez des questions ou avez besoin de plus d'informations à reproduire, veuillez me le faire savoir.
shmendo
Tous les 6 commentaires
@BridgeAR @iamjem Cela pourrait être lié à # 1249
jdegger
le 5 juil. 2017
Merci pour votre description détaillée, cependant je n'ai pas encore pu la reproduire. Lorsque j'émets un SAVE via redis-cli, la connexion n'est pas réinitialisée.
Lorsque j'arrête manuellement le serveur redis et que je le redémarre, il semble bien recevoir des messages.
J'ai testé ceci sur Mac, j'essaierai de le reproduire aussi sous Linux
jdegger
le 5 juil. 2017
Hmmm ... c'est intéressant. Cela se produisait avec une installation redis totalement stockée à partir des sources. La seule option que j'ai modifiée était d'autoriser les connexions à distance. Je vais jeter un coup d'œil sous peu et voir si je peux comprendre ce qui se passe. @jdegger
shmendo
le 5 juil. 2017
@jdegger Je ne suis pas en mesure de reproduire localement, uniquement dans AWS dans des conditions très spécifiques. Je peux créer une deuxième copie de cette AMI et fournir du code qui vous permettra de reproduire, mais c'est apparemment quelque chose de spécifique à l'exécution dans AWS. Faites-moi savoir si vous êtes intéressé ... sinon je dirais d'aller de l'avant et de clôturer le problème
shmendo
le 5 juil. 2017
Ok, enfin capable de reproduire de manière fiable. Il y a quelques exigences:
- redis 3.2.0 - DOIT définir
tcp-keepalive 0 - configurer une chaîne
- configurer le script de nœud pour se connecter et s'abonner au canal
- attendre 2 heures et 1 minute
Ce que vous verrez, c'est que toutes les 2 heures (du moins pour moi) est une erreur ECONNRESET. À ce stade, le socket semble toujours être ouvert dans redis, mais peut-être que le processus de nœud a perdu une référence et ouvert un nouveau socket? Pendant la nuit, j'ai eu comme 1 client connecté par bloc de 2 heures plus le processus en cours d'exécution lors de l'émission de CLIENT LIST de redis-cli.
Il est important de noter que les clients se reconnectaient tous avec succès mais ne recevaient pas de données. J'ai l'impression que les données ont été expulsées, mais à l'ancienne connexion pas à la nouvelle ... mais c'est totalement une intuition.
Maintenant, je ne suis pas sûr à 100% s'il s'agit d'un bogue node_redis ou en fait d'un bogue avec node, donc si ce n'est pas le bon endroit pour déposer, faites le moi savoir. Je serais heureux d'essayer de déboguer / de passer en revue, mais j'ai peu de temps.
Le correctif consistait à définir tcp-keepalive 300 qui maintient la connexion active ... mais cela semble bancal car le client devrait pouvoir se reconnecter avec succès.
shmendo
le 6 juil. 2017
@shmendo
Notre montre également que l'erreur ECONNRESET se produit toutes les 2 heures. Mais j'ai vérifié tcp-keepalive, c'est 300
CONFIG GET tcp-keepalive
1) "tcp-keepalive"
2) "300"
Fundebug
le 5 mars 2019
Questions connexes
ghost
·
3Commentaires
aletorrado
·
6Commentaires
b96705008
·
7Commentaires
betimer
·
5Commentaires
adamgajzlerowicz
·
4Commentaires
Commentaire le plus utile
Ok, enfin capable de reproduire de manière fiable. Il y a quelques exigences:
tcp-keepalive 0Ce que vous verrez, c'est que toutes les 2 heures (du moins pour moi) est une erreur ECONNRESET. À ce stade, le socket semble toujours être ouvert dans redis, mais peut-être que le processus de nœud a perdu une référence et ouvert un nouveau socket? Pendant la nuit, j'ai eu comme 1 client connecté par bloc de 2 heures plus le processus en cours d'exécution lors de l'émission de
CLIENT LISTde redis-cli.Il est important de noter que les clients se reconnectaient tous avec succès mais ne recevaient pas de données. J'ai l'impression que les données ont été expulsées, mais à l'ancienne connexion pas à la nouvelle ... mais c'est totalement une intuition.
Maintenant, je ne suis pas sûr à 100% s'il s'agit d'un bogue node_redis ou en fait d'un bogue avec node, donc si ce n'est pas le bon endroit pour déposer, faites le moi savoir. Je serais heureux d'essayer de déboguer / de passer en revue, mais j'ai peu de temps.
Le correctif consistait à définir
tcp-keepalive 300qui maintient la connexion active ... mais cela semble bancal car le client devrait pouvoir se reconnecter avec succès.