سلوك وظائف VersionCheck الفاشلة

عذرًا إذا لم تكن هذه الفئة الصحيحة لهذا.

أقوم بتقييم discourse وتفشل مهمة VersionCheck في بيئتي.

لقد لاحظت أن المهام الفاشلة تتراكم داخل sidekiq ومن المحتمل أن يتم نقلها إلى قسم “dead” بعد 25 محاولة افتراضية (وفقًا لـ https://www.rubydoc.info/gems/sidekiq/Sidekiq/JobRetry).

أعلم أنني بحاجة إلى التحقيق في سبب فشلها، ولكن النقطة هنا هي: هل من المنطقي الاحتفاظ بهذه المهام هناك؟ أليس من الأفضل ببساطة تجاهل عمليات التحقق من الإصدار الفاشلة والانتظار حتى التنفيذ التالي للمهمة؟

في الوقت الحالي، لدي أكثر من 80 مهمة VersionCheck تنتظر إعادة المحاولة، وبالنسبة لي يبدو ذلك إهدارًا للموارد (ربما قليلًا، ولكنه لا يزال إهدارًا)…

مما فحصته، فإن إضافة sidekiq_options retry: false إلى app/jobs/scheduled/version_check.rb سيحل هذه المشكلة.

هل أغفل شيئًا؟

كيف قمت بالتثبيت؟ هل هناك سبب للاعتقاد بأن لديك مشاكل في الشبكة؟ ذاكرة الوصول العشوائي؟

قد تكون على حق، ولكن نظرًا لأنك الشخص الوحيد الذي أبلغ عن ذلك (على الأقل حتى الآن)، فإنه لم يصل إلى قائمة التحسينات. يبدو من المنطقي تركه يفشل بعد محاولة واحدة، أعتقد.

متى كانت آخر مرة قمت فيها بالترقية؟

كانت هناك مشكلة في وظيفة التحقق من الإصدار قبل بضعة أسابيع (حوالي نهاية أكتوبر)، وقد تم إصلاحها الآن. إذا قمت بالترقية في الطرفية (./launcher rebuild app)، فيجب أن يكون كل شيء على ما يرام.

إعجاب واحد (1)

أنا أستخدم التثبيت القياسي لـ docker داخل مثيل ec2.

أنا في بيئة مؤسسية، لذا هناك الكثير من جدران الحماية والوكلاء وماسحات الأمان بين المثيل والإنترنت. في السجلات، أرى خطأ “Job exception: Connection reset by peer - SSL_connect (Errno::ECONNRESET)”، لذا ربما يقوم جدار حماية ما بمنع الطلب في نقطة ما… ما زلت أفهم كيف يقوم discourse بإجراء فحوصات الإصدار هذه حتى أتمكن من تكرارها يدويًا والحصول على مزيد من التفاصيل.

أتفهم هذا تمامًا. في الماضي، عملت مع gitlab ورأيت الكثير من المشكلات حيث تسببت قوائم انتظار sidekiq الكاملة في تدهور الأداء وسلوكيات غريبة أخرى، لذا في كل مرة أرى شيئًا كهذا، تدق أجراس الإنذار لدي. :smile:

إعجاب واحد (1)

أنا على 2.8.0.beta9 (959923d3cf)

نعم… الترقية في الطرفية أو عبر الواجهة الرسومية تعمل بشكل جيد (أقوم بتشغيلها أسبوعيًا). المشكلة الوحيدة في هذه الحالة هي أن شاشة المسؤول الرئيسية لا تعرض أحدث إصدار وتقول دائمًا أنني أقوم بتشغيل إصدار قديم.

إذًا، يجب عليك بالتأكيد تشغيل ترقية سطر الأوامر

سيقوم Discourse بالوصول إلى الإنترنت لمهام مثل التحقق من ترقيات الإصدار، وجلب صور المستخدمين، وتنزيل الصور البعيدة إلى التخزين المحلي، والـ oneboxing العام. إذا تم فصل المثيل عن الإنترنت، فستكون هناك بعض المشاكل بالتأكيد.

إعجاب واحد (1)

نعم! أقوم بذلك كل أسبوع حتى أجد حلاً.

اضطررت للتخلي عن الـ oneboxing لهذا السبب بالضبط. في الوقت الحالي، لا يمكنني السماح بالوصول الكامل إلى الإنترنت لهذا الخادم.
github.com/* مسموح به بالفعل، ولكن ربما تستخدم وظيفة التحقق من الإصدار هذه عنوان URL آخر للقيام بذلك.

إعجاب واحد (1)

ما سأفعله هو إيقاف SiteSetting.version_checks، وإزالة المكون الإضافي discourse_docker وإجراء ترقيات سطر الأوامر.

ولكن، هنا، إذا كان بإمكانك فتح https://api.discourse.org/api، فمن المحتمل أن تكون على ما يرام.

إعجاب واحد (1)

شكراً على المعلومات! لقد نجحت عندما سمحت بالوصول إلى https://api.discourse.org/api/version_check

إعجاب واحد (1)