Tout d’abord, c’est une autre question / un autre sujet sur la file d’email 1.9.1. Mais il ne s'agit pas de problèmes cron (comme celui-ci ou celui-ci ) ou de la nouvelle fonctionnalité de file d'attente qui n'est pas utilisée (comme ceci ).
Dans notre cas, le problème était que la file d'attente ( core_email_queueet core_email_queue_recipients) ne recevait tout simplement pas d'e-mails concernant les nouvelles commandes ou les mises à jour des commandes. Par conséquent, aucun autre e-mail n'a été envoyé pour les commandes. Cron fonctionne parfaitement et l'ajout manuel à la file d'attente fonctionne et ils sont envoyés.
La chose étrange est que, dans notre environnement de test, tout a fonctionné. Même lorsque nous sommes entrés en ligne aujourd’hui dans les premières minutes, tous les e-mails ont été traités, mais après quelques minutes (sans aucune modification supplémentaire sur le système en direct), aucun nouvel e-mail n’a été ajouté à la file. Il semble que cela se soit produit (mais je ne le sache pas avec certitude) lorsque le premier client a utilisé PayPal Express, ce que nous n'avions pas testé auparavant: - / Nous utilisions en effet des substitutions personnalisées dans la logique de PayPal Express avec l'ancienne sendNewOrderEmail()fonction. Mais nous ne pouvions pas faire fonctionner les emails même après avoir corrigé ceux-ci queueNewOrderEmail().
La première question serait donc: est-il possible que l’ancienne fonction déclenche une incohérence qui «casse» la file d'attente de messagerie? Ou est-ce juste une grosse coïncidence et une explication totalement différente?
Comme nous ne pouvions pas trouver le problème mais que, bien sûr, nous avions besoin que les courriels fonctionnent à nouveau dès que possible, nous avons opté pour un autre remplacement prioritaire. Dans Mage_Core_Model_Email_Template_Mailer(bien sûr, dans une copie local), nous avons commenté la ligne 76: ->setQueue($this->getQueue())
cela semble ignorer la file d'attente et tous les e-mails sont à nouveau envoyés à l'ancienne.
Cependant, comme nous aimerions limiter au minimum le nombre de modifications de base, nous ne pouvons pas dire pour le moment si nous ferons face à d’autres effets secondaires, conseils ou solutions de personnes connaissant mieux le code magento et les la file d'attente d'email serait appréciée.
Mise à jour pour la version 1.9.2: lors de la mise à niveau vers la version 1.9.2, nous avons à nouveau examiné de plus près la file d'attente de messagerie et n'avons pas pu reproduire le problème. Mais comme nous ne savons toujours pas quel était le problème avec la version 1.9.1 et que la résolution du problème Mage_Core_Model_Email_Template_Mailer::send()fonctionne toujours de la manière décrite ici, nous n’utilisons toujours pas la file d’attente. De cette façon, nous espérons ne plus avoir le même problème après un certain temps de production.
tl; dr: La file d’e-mails ne fonctionne pas dans la version 1.9.1, la ligne 76 est mise en commentaire et Mage_Core_Model_Email_Template_Mailercontourne la file. Comment cela peut-il être mieux résolu?
la source
exception.logou éventuellementsystem.log, y a-t-il des indices?coreetc. pour nous assurer que tout ce qui n’est pas personnalisé ou une extension est en place et non modifié et c'est). Les autorisations correspondent à l'ancienne configuration et les journaux / rapports sont propres.core_email_queue_send_allpour qu'il s'exécute également toutes les minutes et à partir duquel nous voyons qu'il est réellement exécuté.Réponses:
Mon hypothèse est que la configuration de cron.php pour s'exécuter chaque minute a provoqué la superposition de nombreux éléments, c'est-à-dire qu'ils ne se terminent pas avant l'exécution de la prochaine tâche planifiée de même nature ou similaire. Depuis les deux cron.php ne serait pas au courant de chaque état. Le même enregistrement peut être tenté deux fois, ce qui provoque une exception étrange lors de l'enlèvement des envois de courrier électronique dans la file d'attente.
Cela dit, il y a
Mage::Logdes exceptions dans le courrier en file d'attente. S'assurer que la journalisation est activée serait donc la meilleure étape pour aider à déterminer s'il existe des exceptions. Il peut être judicieux de lancer également l'php -f cron.phpinterface CLI pour voir si elle génère également des exceptions, car vous ne le verrez peut-être pas dans les coulisses.Je commencerais également par un simple
mail()test PHP pour vous assurer que vous ne rencontrez aucune stratégie anti-spam. Juste pour être sûr que ce n'est pas quelque chose de plus bas dans la pile qui cause le problème.Juste quelques spéculations, espérons que cela aide!
* MODIFIER *
Utilisez à la
cron.shplace decron.phpce qui sera faitgrep pspour voir si un processus précédent est déjà en cours d'exécution.la source
Vérifiez si core_email_queue et core_email_queue_recipients a AUTO_INCREMENT. Si ces tables n'ont pas activé l'IA, les nouvelles entrées ne seront pas prises en compte.
la source