Magento 1.9.1 Email Queue funktioniert nicht / fehlerhaft - wie kann ich Probleme beheben und welcher Patch ist der beste?

Zuallererst ja, dies ist eine weitere Frage / ein weiteres Thema zur 1.9.1-E-Mail-Warteschlange. Es geht aber nicht um irgendwelche Cron-Probleme (wie dieses oder jenes ) oder darum, dass die neue Warteschlangenfunktion nicht verwendet wird (wie dieses ).

In unserem Fall hatten wir das Problem, dass die Warteschlange ( core_email_queueund core_email_queue_recipients) einfach keine E-Mails zu neuen Bestellungen oder Auftragsaktualisierungen mehr bekam und daher keine E-Mails mehr für irgendetwas mit Bezug auf die Bestellung verschickt wurden. Außerdem funktioniert cron perfekt und fügt E-Mails manuell hinzu Die Warteschlange funktioniert und sie werden versendet.

Das Seltsame ist, dass in unserer Testumgebung alles funktioniert hat. Selbst als wir heute in den ersten Minuten online gingen, wurden alle E-Mails verarbeitet, aber nach einigen Minuten (natürlich ohne weitere Änderungen im Live-System) wurden überhaupt keine neuen E-Mails mehr in die Warteschlange aufgenommen. Es scheint, als wäre dies passiert (aber ich kann es nicht genau sagen), als der erste Kunde PayPal Express verwendet hat, was wir vorher nicht getestet haben: - / Und tatsächlich haben wir einige benutzerdefinierte Überschreibungen in der PayPal Express-Logik mit der alten sendNewOrderEmail()Funktion verwendet. Aber wir konnten E-Mails nicht wieder zum Laufen bringen, selbst nachdem wir diese für die Verwendung gepatcht hatten queueNewOrderEmail().
Die erste Frage wäre also, ob es möglich ist, dass die alte Funktion eine Inkonsistenz auslöst, die "kaputt geht". die E-Mail-Warteschlange? Oder ist das alles nur ein großer Zufall und es gibt eine ganz andere Erklärung?

Da wir das Problem nicht finden konnten, aber natürlich E-Mails brauchten, um so schnell wie möglich wieder funktionieren zu können, entschieden wir uns für einen weiteren Core-Override. In Mage_Core_Model_Email_Template_Mailer(natürlich in einer Kopie in local) haben wir Zeile 76 ->setQueue($this->getQueue())
auskommentiert : Dies scheint die Warteschlange zu umgehen und alle Mails werden wieder auf die alte Weise gesendet.

Da wir jedoch die Anzahl der Core-Overrides auf ein Minimum beschränken möchten, können wir derzeit auch nicht sagen, ob wir anderen Nebenwirkungen, anderen Tipps oder Lösungen von Personen mit einem tieferen Verständnis des Magento-Codes und des Magento-Codes gegenüberstehen E-Mail-Warteschlange wäre dankbar.

Update für 1.9.2: Beim Upgrade auf 1.9.2 haben wir uns die E-Mail-Warteschlange noch einmal genauer angesehen und konnten das Problem nicht reproduzieren. Da wir jedoch immer noch keine wirkliche Ahnung haben, wo das Problem mit 1.9.1 lag, und das Überschreiben Mage_Core_Model_Email_Template_Mailer::send()immer noch auf die hier beschriebene Weise funktioniert, verwenden wir die Warteschlange immer noch nicht. Auf diese Weise hoffen wir, dass wir nach einiger Zeit in der Produktion nicht mehr auf dasselbe Problem stoßen.

tl; dr: Die E-Mail-Warteschlange funktioniert in 1.9.1 nicht. Wenn Sie Zeile 76 in auskommentieren, wird Mage_Core_Model_Email_Template_Mailerdie E-Mail-Warteschlange umgangen und die E-Mails werden erneut gesendet, aber dies scheint keine gute Lösung zu sein. Wie kann das besser gelöst werden?

email ce-1.9.1.0 cron

— Jey DWork
quelle

Wie viele Testtransaktionen haben Sie ausgeführt, verglichen mit wie vielen Live-Transaktionen in den ersten Minuten? War dies ein Upgrade von einer älteren Version und einige Dateien fehlen oder haben falsche Berechtigungen? Wie wäre es mit exception.logoder möglicherweise system.loggibt es dort irgendwelche Hinweise?

— Pspahn

Es war ein Upgrade von 1.9.0.1 und es wurde nicht über den Connect-Manager, sondern über die Magento-Codebasis durchgeführt. Ich bezweifle daher, dass wir Dateien fehlen (wir haben auch Unterschiede coreusw. vorgenommen, um sicherzustellen, dass alles, was nicht angepasst ist oder eine Erweiterung vorhanden ist, und unverändert und es ist). Berechtigungen stimmen mit den alten Einstellungen überein und Protokolle / Berichte sind sauber.

— Jey DWork

Ist cron gleich eingerichtet?

— Pspahn

Als wir sahen, dass sich die E-Mail im Änderungsprotokoll geändert hat, haben wir cron so geändert, dass es alle 5 Minuten ausgeführt wird (da wir die Änderung so verstehen, dass Kunden im schlimmsten Fall bis zu 5 Minuten auf ihre Bestätigungs-E-Mails warten müssten). Ansonsten ändert sich nichts und wie gesagt und wir sehen von anderen Jobs cron läuft ohne Probleme. // edit: Ich sollte wahrscheinlich hinzufügen, dass wir Aoe_Scheduler verwenden (und immer verwendet haben), wobei wir festlegen core_email_queue_send_all, dass es auch jede Minute ausgeführt wird und von wo aus wir sehen, dass es tatsächlich ausgeführt wird.

— Jey DWork

Q4 2015 und ich haben das gleiche Problem. Ich kann bestätigen, dass in den Warteschlangentabellen für einige Aufträge keine Einträge vorhanden sind. Dies ist ein deutliches Zeichen, um zu bestätigen, dass keine E-Mails empfangen wurden. Leider wurde die Protokollierung in meinem Fall deaktiviert, sodass ich noch keine Fehler zu suchen habe. Haben Sie seit dem ersten Post etwas Neues gelernt, das hilfreich sein könnte, um es hinzuzufügen?

— Rick Buczynski

Antworten:

Ich vermute, dass die Einstellung von cron.php, die jede Minute ausgeführt wird, dazu geführt hat, dass viele Dinge übereinander stehen, dh erst beendet werden, wenn die nächste geplante Aufgabe gleicher oder ähnlicher Art ausgeführt wird. Da beide cron.php nicht jeden Zustand kennen würden. Es könnte zweimal versucht werden, denselben Datensatz zu speichern, wodurch die E-Mail-Sendevorgänge in der Warteschlange ausnahmsweise unterbrochen werden.

Mage::LogNach alledem gibt es in der Warteschlange Ausnahmen. Wenn Sie also sicherstellen, dass die Protokollierung aktiviert ist, ist dies der beste Schritt, um festzustellen, ob es Ausnahmen gibt. Es kann ratsam sein, auch nur php -f cron.phpvon CLI aus zu starten, um zu prüfen, ob es auch Ausnahmen gibt. Sie können möglicherweise nicht sehen, wie es hinter den Kulissen ausgeführt wird.

https://github.com/OpenMage/magento-mirror/blob/magento-1.9/app/code/core/Mage/Core/Model/Email/Queue.php#L246

Ich würde auch mit einem einfachen PHP- mail()Test beginnen, um sicherzustellen, dass Sie keine Spam-Richtlinien oder ähnliches antreffen. Nur um sicherzugehen, dass es sich nicht um etwas Niedrigeres im Stapel handelt, das das Problem verursacht.

Magento E-Mail-Versand funktioniert nicht

Nur ein paar Spekulationen, hoffe es hilft!

* EDIT *

Verwenden Sie cron.shstatt cron.phpwie es tun wird , grep psum zu sehen , wenn ein vorheriger Prozess bereits ausgeführt wird .

https://github.com/OpenMage/magento-mirror/blob/magento-1.9/cron.sh#L46

— B00MER
quelle

Vielen Dank für die Eingabe, aber diese Probleme können ziemlich sicher ausgeschlossen werden. Nur weil der eigentliche System-Cron-Job jede Minute ausgeführt wird, bedeutet dies nicht, dass alle Magento-Cron-Jobs ausgeführt werden. In unserem Fall wurde nur die E-Mail-Funktion so eingerichtet, dass sie auch jede Minute ausgeführt wird. Aus dem Magentos-Cron-Protokoll können wir ersehen, dass alle Cron-Jobs erfolgreich ausgeführt werden - auch in "stressigen" Minuten (dh jede Stunde oder so, wenn mehrere Jobs gleichzeitig ausgeführt werden und nicht nur E-Mails ). Die Protokollierung ist ebenfalls aktiviert und es werden überhaupt keine Ausnahmen ausgelöst. Das Aufrufen von Spamfiltern kann ausgeschlossen werden, und nach der Problemumgehung, die ich veröffentlicht habe, erreichen alle E-Mails alle Kunden.

— Jey DWork

Möglicherweise möchten Sie versuchen, den Entwicklermodus zu aktivieren, um festzustellen, ob Ausnahmen generiert werden, die nicht protokolliert werden. Seien Sie jedoch vorsichtig, wenn es in Produktion ist. Auch irgendwelche korrelierenden Web-Server-Protokolle?

— B00MER

@JeyDWork hast du Aoe_Scheduler implementiert ? Dies kann eine gute Sichtbarkeit ergeben.

— benmarks

Würde gerne ein Update sehen. Die E-Mail-Warteschlange ist für viele eine Herausforderung.

— benmarks

Für mich habe ich den Paypal-Standard verwendet, der eine IPN-Datenrückgabe (Instant Payment Notification) von Paypal benötigt, um zu bestätigen, dass die Zahlung erfolgreich war, und den Bestellstatus in "Bearbeitung / Abgeschlossen" zu ändern und schließlich eine E-Mail zu senden. Ich hatte jedoch keine tatsächliche Domain eingerichtet für meinen server und vhosts war das der grund, warum paypal keine ipn daten an magento senden konnte. Sie können den IPN-Verlauf im PayPal-Geschäftskontoprofil überprüfen. Paypal zeigte tatsächlich die Daten, die gesendet werden sollten und der Status war "Wiederholen".

— zaw

Überprüfen Sie, ob core_email_queue und core_email_queue_recipients den Wert AUTO_INCREMENT haben. Wenn für diese Tabelle keine KI aktiviert ist, werden keine neuen Einträge akzeptiert.

— Ali Exalter
quelle