Node-redis: الاشتراكات لا تتلقى البيانات بعد إعادة الاتصال
node_redis : 2.7.1
redis : 3.2
المنصة : أمازون لينكس
وصف:
عند حدوث لقطة redis ، يتم قطع اتصال عميل redis. يعيد العميل الاتصال ويعيد الاشتراك ، ومع ذلك ، لم يعد يتلقى البيانات. يمكن إعادة إنتاج ذلك عن طريق إصدار أمر SAVE عبر redis-cli.
شبيبة
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');
السجلات
الاتصال الأولي
info: Connected to Redis
info: subscription_set:
info: Subscribed to: test 1
إصدار أمر حفظ في 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
في هذه المرحلة ، لن يتلقى العميل بعد الآن أي بيانات منشورة لاختبار القناة. إذا كانت لديك أي أسئلة أو كنت بحاجة إلى مزيد من المعلومات لإعادة إنتاجها ، فيرجى إبلاغي بذلك.
shmendo
ال 6 كومينتر
BridgeARiamjem قد تكون ذات صلة # 1249
jdegger
في ٥ يوليو ٢٠١٧
شكرًا على الوصف التفصيلي الذي قدمته ، ومع ذلك لم أتمكن من إعادة إنتاجه بعد. عندما أقوم بإصدار SAVE خلال redis-cli ، لا يتم إعادة تعيين الاتصال.
عندما أوقف خادم redis يدويًا وأبدأ تشغيله مرة أخرى ، يبدو أنه يستقبل رسائل جيدة.
لقد كنت أختبر هذا على Mac ، وسأحاول إعادة إنتاجه أيضًا على Linux
jdegger
في ٥ يوليو ٢٠١٧
هممم ... هذا مثير للاهتمام. كان يحدث مع تثبيت redis كامل المخزون تم بناؤه من المصدر. كان الخيار الوحيد الذي قمت بتغييره هو السماح بالاتصالات عن بُعد. سألقي نظرة بعد قليل وأرى ما إذا كان بإمكاني اكتشاف الأمر. jdegger
shmendo
في ٥ يوليو ٢٠١٧
jdegger لست قادرًا على إعادة النسخ محليًا ، فقط في AWS في ظل ظروف فائقة التحديد. يمكنني إنشاء نسخة ثانية من AMI وتوفير رمز يسمح لك بإعادة الإنتاج ، لكن يبدو أنه شيء خاص بالتشغيل في AWS. اسمحوا لي أن أعرف ما إذا كنت مهتمًا ... وإلا سأقول المضي قدمًا وإغلاق المشكلة
shmendo
في ٥ يوليو ٢٠١٧
حسنًا ، أخيرًا قادر على التكاثر بشكل موثوق. هناك بعض المتطلبات:
- redis 3.2.0 - يجب تعيين
tcp-keepalive 0 - قم بإعداد قناة
- تكوين البرنامج النصي العقدة للاتصال والاشتراك في القناة
- انتظر ساعتين ودقيقة واحدة
ما ستراه هو أن كل ساعتين (على الأقل بالنسبة لي) هو خطأ ECONNRESET. في هذه المرحلة ، يبدو أن المقبس لا يزال مفتوحًا في redis ولكن ربما فقدت عملية العقدة مرجعًا لها وفتحت مقبسًا جديدًا؟ بين عشية وضحاها كان لدي عميل واحد متصل كل ساعتين بالإضافة إلى العملية الجارية عند إصدار CLIENT LIST من redis-cli.
من المهم ملاحظة أن العملاء كانوا جميعًا يعيدون الاتصال بنجاح ولكنهم لا يتلقون البيانات. لدي حدس مفاده أن البيانات تم دفعها للخارج ، ولكن الاتصال القديم ليس الجديد ... لكن هذا حدس تمامًا.
الآن ، لست متأكدًا بنسبة 100٪ مما إذا كان هذا خطأ في node_redis أو خطأ في العقدة ، لذلك إذا كان هذا هو المكان الخطأ لتقديمه ، فأخبرني بذلك. يسعدني أن أحاول تصحيح الأخطاء / الخطوة ولكن لدي وقت محدود.
كان الإصلاح هو تعيين tcp-keepalive 300 الذي يحافظ على الاتصال نشطًا ... لكن هذا يبدو متزعزعًا لأن العميل يجب أن يكون قادرًا على إعادة الاتصال بنجاح.
shmendo
في ٦ يوليو ٢٠١٧
تضمين التغريدة
يظهر لنا أيضًا أن خطأ ECONNRESET يحدث كل ساعتين. لكنني تحققت من tcp-keepalive ، فهو 300
CONFIG GET tcp-keepalive
1) "tcp-keepalive"
2) "300"
Fundebug
في ٥ مارس ٢٠١٩
القضايا ذات الصلة
twappworld
·
7تعليقات
michaelwittig
·
3تعليقات
Stono
·
6تعليقات
adamgajzlerowicz
·
4تعليقات
strumwolf
·
4تعليقات
التعليق الأكثر فائدة
حسنًا ، أخيرًا قادر على التكاثر بشكل موثوق. هناك بعض المتطلبات:
tcp-keepalive 0ما ستراه هو أن كل ساعتين (على الأقل بالنسبة لي) هو خطأ ECONNRESET. في هذه المرحلة ، يبدو أن المقبس لا يزال مفتوحًا في redis ولكن ربما فقدت عملية العقدة مرجعًا لها وفتحت مقبسًا جديدًا؟ بين عشية وضحاها كان لدي عميل واحد متصل كل ساعتين بالإضافة إلى العملية الجارية عند إصدار
CLIENT LISTمن redis-cli.من المهم ملاحظة أن العملاء كانوا جميعًا يعيدون الاتصال بنجاح ولكنهم لا يتلقون البيانات. لدي حدس مفاده أن البيانات تم دفعها للخارج ، ولكن الاتصال القديم ليس الجديد ... لكن هذا حدس تمامًا.
الآن ، لست متأكدًا بنسبة 100٪ مما إذا كان هذا خطأ في node_redis أو خطأ في العقدة ، لذلك إذا كان هذا هو المكان الخطأ لتقديمه ، فأخبرني بذلك. يسعدني أن أحاول تصحيح الأخطاء / الخطوة ولكن لدي وقت محدود.
كان الإصلاح هو تعيين
tcp-keepalive 300الذي يحافظ على الاتصال نشطًا ... لكن هذا يبدو متزعزعًا لأن العميل يجب أن يكون قادرًا على إعادة الاتصال بنجاح.