لقد قمنا بالانتقال من قائمة بريدية، ولا يزال العديد من المستخدمين يستخدمون المنتدى بشكل رئيسي عبر البريد الإلكتروني.
هناك حوالي 300 مستخدم في وضع القائمة البريدية. لكن يبدو أن Discourse ترسل فقط حوالي 75 إلى 80 بريدًا إلكترونيًا عند إضافة موضوع جديد.
قارنت إعدادات المستخدمين في القائمة البريدية لأعضاء مختلفين ووجدتها متطابقة.
لا يوجد أي شيء في قسم المستبعد.
لا أعرف أين أبحث عن السبب المحتمل لهذه المشكلة.
هل جميع المستخدمين مفعلون؟ ربما لا يستلمون أي بريد إلكتروني؟
نعم، كل ذلك مفعل.
ويبدو الأمر عشوائيًا للأسف، لدي عدة حسابات أستخدمها لإعداد الأشياء وتتصرف بشكل مختلف أيضًا.
الآن راجعت بعض المواضيع الأقدم هنا ويبدو أن الأمر مشابه: https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
قد يكون نفس المشكلة. ومع ذلك، لا أعرف كيفية تغيير الإعدادات كما هو مقترح في الحل في ذلك المنشور.
أحاول تشغيل هذا:
User.find_by_username(‘Neuer.test’).mailing_list_mode
ولكن أحصل على:
NoMethodError: undefined method `mailing_list_mode’ for #User:0x00005569c4038af8
وضع القائمة البريدية مُعد في جدول user_options. جرّب تشغيل UserOption.where(mailing_list_mode: true). للحصول على معرفات المستخدمين لكل المستخدمين الذين تم تفعيل وضع القائمة البريدية لديهم، شغّل UserOption.where(mailing_list_mode: true).pluck(:user_id)
شكرًا لك @simon
لقد قمت بتوليد قائمة كما اقترحت في منشورك. في الواقع، إنها عدة قوائم. يقوم بتوليد قائمة معرفات المستخدمين، ثم يصل إلى حوالي 50 ويظهر :...skipping...، ثم يبدأ من جديد بنفس معرفات المستخدمين، مضافًا معرفًا جديدًا في الأسفل، ويكرر هذه العملية حوالي 4 أو 5 مرات. وبين ذلك، هناك قسم كامل من الأسطر الفارغة فقط. لكن قد يكون هذا سلوكًا طبيعيًا؟
على أي حال، هذه القائمة ليست قريبة من قائمة كاملة للمستخدمين المشتركين عبر وضع القائمة البريدية (فقط 58، بينما أتوقع حوالي 350).
ثم قمت بتشغيل بعض الفحوصات على المعرفات، ولم يتلقَ أي منها آخر منشور على سبيل المثال.
كما قمت بتشغيل UserOption.where(mailing_list_mode: false).pluck(:user_id) والذي أعاد 29 إدخالًا آخر.
أما تشغيل UserOption.where(mailing_list_mode: 1).pluck(:user_id) فقد أعاد رقمًا مشابهًا لـ true ونفس المستخدمين.
في المجمل، وجدت فقط حوالي 90 من أصل 400 مستخدم مفعل. كل هذا غريب جدًا ولا أفهم ما الذي يحدث.
أي مساعدة موصوفة جدًا ومقدرة.
ملاحظة: كيف يمكنني الخروج بعد آخر : في أسفل نتائج البحث، حتى أتمكن من تشغيل استعلام آخر؟
عندما يعيد الاستعلام نصًا أكثر مما يتسع للشاشة، يعرضه بشكل أقل. يمكنك البحث على جوجل لمعرفة كيفية عمل ذلك.
المسافة ستنتقل إلى الشاشة التالية، / للبحث، و q للخروج.
لذا أعتقد أنه يبدو وكأنك تتلقى بريدًا موجهًا إلى المستخدمين النشطين. قد يكون الآخرون غير نشطين؟
شكرًا لك يا جاي.
لا، لدينا أكثر من 450 مستخدمًا نشطًا. لا أستطيع حقًا رؤية نمط محدد. لقد راجعت منشورًا سابقًا من قبل بضعة أيام، وقد تم إرساله إلى 334 مستخدمًا عبر وضع القائمة البريدية.
الشيء الوحيد الذي تغير منذ ذلك الحين هو أننا أضفنا سجل SPF إلى نظام أسماء النطاقات (DNS) الخاص بنا، لأننا كنا نواجه صعوبة في الإرسال إلى Google. لكن ذلك كان على خادم البريد الخاص بنا، ولم أقوم بتغيير أي من إعدادات SMTP في Discourse.
@pfaffman لقد قمت للتو بتثبيت مستكشف البيانات، ربما هناك استعلام يمكنني تشغيله هناك بدلاً من ذلك؟
هذا الأمر بدأ يربكني 
كنتُ على وشك النشر بأن كل شيء بدا وكأنه ‘حلّ بنفسه’، حيث تلقى 336 شخصًا منشورات حديثة مختلفة.
ثم جاء ردّان على منشور واحد في تتابع سريع، كلاهما من مستخدم واحد. تلقى 181 عضوًا كلا الرسالةَين، وتلقى 38 عضوًا رسالةً واحدةً فقط، مما يعني أن 117 عضوًا لم يتلقوا أي رسائل بريد إلكتروني.
هل يوجد سجل آخر يمكنني الاطلاع عليه قد يوضح هذا الأمر؟ لا يوجد شيء في sidekiq.
يبدو أن المشكلة هي خطأ 421.4.7.0: عدد كبير جدًا من الاتصالات من عنوان IP.
وغريبًا، يبدو أن هذا يحدث بشكل رئيسي مع عضو واحد.
كيف يمكنني إصلاح ذلك؟
إليك ما تقوله السجلات:
الرسالة (1957 نسخة تم الإبلاغ عنها)
استثناء المهمة: 421 4.7.0 dd27022.xxxxxx.com خطأ: عدد كبير جدًا من الاتصالات من xxx.xxx.xx.xxx
### تتبع الأثر
/usr/local/lib/ruby/2.6.0/net/smtp.rb:969:in `check_response'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:553:in `do_start'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:518:in `start'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.7.1/lib/mail/message.rb:2159:in `do_delivery'
mail-2.7.1/lib/mail/message.rb:260:in `block in deliver'
actionmailer-6.0.1/lib/action_mailer/base.rb:589:in `block in deliver_mail'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.1/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `instrument'
actionmailer-6.0.1/lib/action_mailer/base.rb:587:in `deliver_mail'
mail-2.7.1/lib/mail/message.rb:260:in `deliver'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:114:in `block in deliver_now'
actionmailer-6.0.1/lib/action_mailer/rescuable.rb:17:in `handle_exceptions'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:113:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:212:in `send'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:90:in `block (2 levels) in execute'
/var/www/discourse/app/models/email_log.rb:35:in `block in unique_email_per_post'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/email_log.rb:31:in `unique_email_per_post'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:89:in `block in execute'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block (2 levels) in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:136:in `block in find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:238:in `block in in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `loop'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:135:in `find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:69:in `find_each'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:61:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.4/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.4/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.4/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.4/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.4/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.4/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.4/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.4/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.4/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.4/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.4/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.4/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.4/lib/sidekiq/util.rb:24:in `block in safe_thread'
يجب عليك الاستفسار من موفر البريد الإلكتروني الخاص بك، فليس لهذا الأمر أي علاقة بـ Discourse.
@codinghorror
لذا قمت بتغيير موفر البريد الإلكتروني وأصبحت الآن أستخدم Amazon SES. بدا أن هذا الحل قد نجح لبضعة أسابيع. الآن، بدأ Discourse يتوقف عشوائيًا عن إرسال البريد في منتصف عملية التوصيل إلى مشتركي القائمة البريدية مرة أخرى. لا توجد أخطاء في السجلات. لقد أعيد بناء الحاوية، ويبدو الآن أن الأمور على ما يرام مرة أخرى. هل هناك مكان آخر يمكنني البحث فيه عن سجل خطأ محتمل؟
هل توجد مهام عالقة في Sidekiq؟
للأسف، لا يوجد.
أواجه مشكلة مماثلة خلال الأيام القليلة الماضية. لا يتم إرسال رسائل البريد الإلكتروني إلى مستخدمي القائمة البريدية، ولا توجد وظائف معلقة في Sidekiq، وأحصل على نفس خطأ السجل. لقد حاولت إعادة البناء، لكن يبدو أن ذلك لا يحدث فرقًا. هذا يسبب بالفعل الكثير من الضيق لمستخدمينا.
يبدو أن ما يحدث هو أنه بعد إعادة البناء، إذا تم استلام منشور جديد، يتم إرساله، ولكن بعد ذلك لا يتم إرسال أي منشورات أو ردود لاحقة.
أي مساعدة ستكون محل تقدير كبير!
إد
هذا الأمر يتحول إلى مشكلة محبطة للغاية بالنسبة لي.
اليوم قرر Discourse التوقف عن الإرسال إلى مشتركين في القائمة البريدية بعد تسليم 15 بريدًا إلكترونيًا فقط. ليست المشكلة من جانب مزود الخدمة، حيث قمت بالفعل بتغيير المزود. كما لا توجد رسائل خطأ في السجلات أو أي شيء عالق في Sidekiq.
أعتقد أن الحل الوحيد المتاح هو إعادة البناء.
هل توجد طريقة يمكنني من خلالها جدولة إعادة البناء تلقائيًا لفترات زمنية محددة؟ على الأقل لن أضطر إلى مراقبته باستمرار.
يمكنك إعداد مهمة مجدولة (cron job) للقيام بذلك.
هل لم يصل عدد رسائل البريد الإلكتروني القصوى المسموح بها في اليوم لبعض المستخدمين؟ هل لم يقوموا بتعطيل رسائل البريد الإلكتروني؟ (وهذا لا يفسر سبب إصلاح إعادة البناء لأي شيء). هل لديك ذاكرة وصول عشوائي (RAM) كافية؟ هل لا يوجد شيء في السجلات؟
رسالة الخطأ out of memory واضحة جدًا.
تحرير: أوه، لقد خلطت بينك وبين موضوع آخر، لذا فإن هذه المعلومات حول الموقع متعدد المواقع، رغم صحتها، قد لا تكون ذات معنى هنا.
أنا متأكد تقريبًا من أن مثيلتي الخاصة بالموقع متعدد المواقع تعمل بذاكرة عشوائية (RAM) مقدارها 4 جيجابايت، لكن هذا لا يشمل أيضًا تشغيل mysql و apache و wordpress. لقد سببت لي موقعي الذي يجمع بين (staging + production)*(discourse + wordpress) الكثير من المتاعب قبل أن أزيده إلى 8 جيجابايت. ويشمل ذلك حاويات لـ postgres و redis و traefik و prometheus و mariadb، بالإضافة إلى حاويتين لكل من WordPress و Discourse (وليس موقعًا متعدد المواقع، لأن مرحلة الاختبار تحتاج إلى إمكانية امتداد إضافات مختلفة عن مرحلة الإنتاج).
إذا كان توفير المال هو هدفك ولديك مواقع Discourse ذات حجم منخفض، فإن وضع كل منها على خادم (droplet) منفصل بقيمة 5 دولارات (1 جيجابايت) هو على الأرجح الخيار الأفضل.
نعم، لقد أدركت ذلك 
أنا أستخدم وحدة معالجة مركزية مشتركة قياسية وأقوم بتشغيل موقع Discourse واحد فقط على قطرة السحابة الخاصة بي.