Abbiamo migrato da una mailing list e molti utenti utilizzano ancora il nostro forum prevalentemente tramite email.
Ci sono circa 300 utenti in modalità mailing list. Tuttavia, Discourse sembra inviare solo circa 75-80 email quando viene aggiunto un nuovo argomento.
Ho confrontato le impostazioni degli utenti per la mailing list di vari membri e sono tutte uguali.
Non c’è nulla nella sezione “saltati”.
Non so dove cercare per capire cosa potrebbe causare questo problema.
Tutti gli utenti sono attivati? Forse non ricevono alcuna email?
Sì, sono tutti attivati.
Purtroppo sembra anche casuale: ho alcuni account che uso per configurare le cose e si comportano diversamente.
Ora ho dato un’occhiata ad alcuni argomenti più vecchi qui e sembra simile: https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
Potrebbe essere lo stesso problema. Tuttavia, non so come modificare le impostazioni come suggerito nella soluzione di quel post.
Sto cercando di eseguire questo:
User.find_by_username(‘Neuer.test’).mailing_list_mode
ma ottengo:
NoMethodError: undefined method `mailing_list_mode’ for #User:0x00005569c4038af8
La modalità mailing list è impostata nella tabella user_options. Prova a eseguire UserOption.where(mailing_list_mode: true). Per ottenere gli ID utente di tutti gli utenti con la modalità mailing list abilitata, esegui UserOption.where(mailing_list_mode: true).pluck(:user_id)
Grazie @simon
Ho generato un elenco come suggerito nel tuo post. In realtà si tratta di diversi elenchi. Genera un elenco di ID utente e poi, dopo circa 50 voci, visualizza :...skipping... per poi ricominciare con gli stessi ID utente, aggiungendone uno nuovo in fondo e ripetendo questo processo circa 4 o 5 volte. Tra un ciclo e l’altro c’è un’intera sezione di righe vuote, ma potrebbe essere un comportamento normale?
In ogni caso, questo non è affatto un elenco completo degli utenti iscritti tramite la modalità Mailing List (solo 58, mentre mi aspettavo circa 350).
Ho poi eseguito alcuni controlli sugli ID e nessuno di loro ha ricevuto l’ultimo post, ad esempio.
Ho anche eseguito UserOption.where(mailing_list_mode: false).pluck(:user_id), che ha restituito altre 29 voci.
L’esecuzione di UserOption.where(mailing_list_mode: 1).pluck(:user_id) ha restituito un numero simile a quello di true e gli stessi utenti.
In totale, ho trovato solo circa 90 dei 400 utenti attivati. È tutto molto strano e non capisco cosa stia succedendo.
Qualsiasi aiuto sarebbe molto apprezzato.
P.S. Come faccio ad uscire dopo l’ultimo : in fondo ai risultati della ricerca, in modo da poter eseguire un’altra query?
Quando la query restituisce più testo di quanto possa essere visualizzato sullo schermo, lo mostra in modo ridotto. Puoi cercare su Google come funziona.
La barra spaziatrice passa alla schermata successiva, / avvia la ricerca e q esce.
Quindi penso che significhi che stai ricevendo posta inviata agli utenti attivi. Gli altri potrebbero essere inattivi?
Grazie, Jay.
No, abbiamo oltre 450 utenti attivi. Non riesco a vedere un pattern: ho esaminato un post precedente di qualche giorno fa, che è stato inviato a 334 utenti tramite la modalità Mailing List.
L’unica cosa cambiata da allora è che abbiamo aggiunto un record SPF al nostro DNS, poiché avevamo problemi nell’invio a Google. Ma questo riguarda il nostro server di posta; non ho modificato alcuna impostazione SMTP in Discourse.
@pfaffman Ho appena installato Data Explorer, forse posso eseguire una query lì invece?
Questo sta iniziando a farmi perdere la testa 
Stavo per scrivere che, in qualche modo, tutto sembrava essersi “risolto da solo”, dato che 336 persone hanno ricevuto vari post recenti.
Poi sono arrivate due risposte a un post in rapida successione, entrambe dallo stesso utente. 181 membri hanno ricevuto entrambi i messaggi, 38 ne hanno ricevuto uno solo, lasciando 117 senza alcuna e-mail.
Esiste un altro registro da qualche parte che potrei consultare per fare luce su questa situazione? Non c’è nulla in Sidekiq.
Il problema sembra essere l’errore 421.4.7.0: troppe connessioni dall’indirizzo IP.
Stranamente, sembra verificarsi principalmente con un solo membro.
Come posso risolvere?
Ecco cosa riportano i log:
Messaggio (1957 copie riportate)
Eccezione del job: 421 4.7.0 dd27022.xxxxxx.com Errore: troppe connessioni da xxx.xxx.xx.xxx
### Backtrace
/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'
Dovrai contattare il tuo provider di posta elettronica, non c’entra nulla con Discourse.
@codinghorror
Quindi ho cambiato il provider di posta e ora sto inviando tramite Amazon SES. Questo sembrava aver risolto il problema per alcune settimane. Ora Discourse ha ricominciato a interrompere casualmente l’invio delle email a metà della consegna agli iscritti alla mailing list. Nessun errore nei log. Ho ricostruito il contenitore e per ora sembra tutto ok di nuovo. C’è qualche altro posto dove posso cercare un eventuale log di errore?
Ci sono attività bloccate in Sidekiq?
No, purtroppo non ci sono.
Sto riscontrando un problema simile negli ultimi giorni. Le email non vengono inviate agli utenti della mailing list, non ci sono lavori in sospeso in Sidekiq e ricevo lo stesso errore nei log. Ho provato a ricostruire il sistema, ma sembra non fare alcuna differenza. Questo sta causando davvero molto disagio ai nostri utenti.
Sembra che dopo una ricostruzione, se viene ricevuto un nuovo post, questo venga inviato, ma dopo di ciò nessun post o risposta successivo venga inviato.
Qualsiasi aiuto sarebbe molto apprezzato!
Ed
Questa sta diventando una questione davvero frustrante per me.
Oggi Discourse ha deciso di smettere di inviare email agli iscritti alla mailing list dopo averne consegnate solo 15. Non è un problema del provider, dato che ho già cambiato fornitore. Inoltre, non ci sono messaggi di errore nei log né nulla bloccato in Sidekiq.
Penso che l’unica soluzione sia un rebuild.
Esiste un modo per pianificare automaticamente un rebuild a intervalli regolari? Almeno così non dovrei monitorarlo continuamente.
Potresti impostare un cron job per farlo.
Non hai raggiunto il limite massimo di email giornaliere per alcuni utenti? Non hanno disattivato le email? (questo non spiegherebbe perché una ricostruzione risolva il problema). Hai abbastanza RAM? Non ci sono errori nei log?
out of memory è un messaggio di errore piuttosto chiaro.
EDIT: Ops. Ho confuso te con un altro argomento, quindi queste informazioni sul multisito, sebbene tutte vere, potrebbero non avere senso in questo contesto.
Sono abbastanza sicuro che la mia istanza dedicata solo al multisito stia funzionando con 4 GB di RAM, ma in quel caso non erano attivi anche MySQL, Apache e WordPress. Il mio sito con (staging + production)*(discourse + wordpress) mi ha creato grossi problemi prima di aumentarlo a 8 GB. Includeva container per PostgreSQL, Redis, Traefik, Prometheus e MariaDB, più due ciascuno per WordPress e Discourse (non in modalità multisito, dato che lo staging deve poter avere plugin diversi dalla produzione).
Se il risparmio è la tua priorità e hai siti Discourse a basso traffico, probabilmente la soluzione migliore è avere ognuno su un droplet separato da 5$ (1 GB).
Sì, l’avevo capito 
Ho una CPU condivisa standard e sto eseguendo solo un sito Discourse sul mio droplet.