Magento 1.9.1 Kolejka e-mail nie działa / nie działa - jak rozwiązywać problemy i jaka jest najlepsza łatka?


35

Przede wszystkim tak, to kolejne pytanie / temat dotyczący kolejki e-mail 1.9.1. Ale to nie jest temat o problemach cron (jak ten lub ten ) lub o nowej funkcji kolejki nie są używane (jak ten ).

W naszym przypadku mieliśmy problem z tym, że kolejka ( core_email_queuei core_email_queue_recipients) po prostu nie otrzymywała żadnych e-maili o nowych zamówieniach lub aktualizacjach zamówień, a zatem nie wysyłano już żadnych e-maili w związku z zamówieniami, również cron działa idealnie i ręcznie dodaje e-maile do kolejka działa i zostają wysłani.

Dziwne jest to, że w naszym środowisku testowym wszystko działało. Nawet kiedy dzisiaj zaczęliśmy działać w ciągu pierwszych minut, wszystkie e-maile zostały przetworzone, ale po kilku minutach (oczywiście bez żadnych dalszych modyfikacji w systemie na żywo) nie pojawiły się żadne nowe e-maile w kolejce. Wygląda na to, że tak się stało (ale nie jestem tego pewien), kiedy pierwszy klient użył PayPal Express, którego wcześniej nie testowaliśmy: - / I rzeczywiście używaliśmy niestandardowych przesłonięć w logice PayPal Express ze starą sendNewOrderEmail()funkcją. Ale nie mogliśmy ponownie uruchomić wiadomości e-mail, nawet po ich poprawieniu queueNewOrderEmail().
Pierwsze pytanie brzmiałoby: czy możliwe jest, że stara funkcja wywołała pewną niespójność, która „zepsuła się” kolejka e-mail? A może to tylko wielki zbieg okoliczności i istnieje zupełnie inne wytłumaczenie?

Ponieważ nie mogliśmy znaleźć problemu, ale oczywiście potrzebowaliśmy ponownie e-maili, jak najszybciej, postanowiliśmy zastąpić inny rdzeń. W Mage_Core_Model_Email_Template_Mailer(oczywiście w kopii w local) skomentowaliśmy linię 76: ->setQueue($this->getQueue())
Wydaje się, że omija ona kolejkę i wszystkie wiadomości są ponownie wysyłane w stary sposób.

Jednakże, ponieważ chcielibyśmy ograniczyć liczbę zastąpień rdzenia do minimum, a także nie możemy w tej chwili powiedzieć, czy napotkamy jakiekolwiek inne skutki uboczne, jakiekolwiek inne wskazówki lub rozwiązania od osób z głębszym zrozumieniem kodu magento i mile widziane będą kolejki e-mail.

Aktualizacja do wersji 1.9.2: Po aktualizacji do wersji 1.9.2 ponownie przyjrzeliśmy się kolejce e-mail i nie byliśmy w stanie odtworzyć problemu. Ponieważ jednak nadal nie mamy pojęcia, na czym polegał problem z wersją 1.9.1, a ponieważ nadpisywanie Mage_Core_Model_Email_Template_Mailer::send()nadal działa w opisany tutaj sposób, nadal nie korzystamy z kolejki. W ten sposób mamy nadzieję, że po jakimś czasie produkcji nie powtórzymy tego samego problemu.

tl; dr: Kolejka e-mail nie działa w wersji 1.9.1, komentowanie linii 76 w Mage_Core_Model_Email_Template_Mailerkolejce pomija kolejkę e-mail i e-maile są wysyłane ponownie, ale nie wydaje się to dobrym rozwiązaniem. Jak można to lepiej rozwiązać?


1
Ile transakcji testowych przeprowadziłeś w porównaniu do liczby transakcji na żywo przeprowadzonych w ciągu pierwszych kilku minut? Czy było to uaktualnienie ze starszej wersji i brakuje niektórych plików lub mają niewłaściwe uprawnienia? Jak o exception.logewentualnie system.log, czy są jakieś tropy tam?
pspahn

To była aktualizacja z wersji 1.9.0.1 i nie została wykonana za pomocą Connect-Managera, ale z bazy kodu Magento, więc wątpię, abyśmy mieli brakujące pliki (zmieniliśmy również coreitp., Aby upewnić się, że wszystko, co nie jest dostosowane lub rozszerzenie jest na miejscu i niezmodyfikowany i tak jest). Uprawnienia są zgodne ze starą konfiguracją, a dzienniki / raporty są czyste.
Jey DWork,

Czy cron jest skonfigurowany tak samo?
pspahn

Gdy widzieliśmy zmianę adresu e-mail w dzienniku zmian, zmieniliśmy crona, aby uruchamiał się co minutę od co 5 minut wcześniej (rozumiemy zmianę, aby w najgorszym przypadku klienci musieli czekać do 5 minut na wiadomości potwierdzające). Poza tym nie ma zmian i jak powiedziano wcześniej, z innych zadań cron działa bez problemów. // edytuj: Prawdopodobnie powinienem dodać, że używamy (i zawsze używaliśmy) Aoe_Scheduler, w którym ustawiliśmy core_email_queue_send_alltakże uruchamianie co minutę i od miejsca, w którym widzimy, że faktycznie zostanie wykonany.
Jey DWork,

W czwartym kwartale 2015 r. Mam ten sam problem. Mogę potwierdzić, że w tabelach kolejek całkowicie brakuje wpisów dla niektórych zamówień, co jest wyraźnym znakiem potwierdzającym, że nie otrzymano żadnych wiadomości e-mail. Niestety rejestrowanie zostało wyłączone w moim przypadku, więc nie mam jeszcze błędów do wyszukania. Czy nauczyłeś się czegoś nowego od czasu opublikowania, które mogą być pomocne w dodaniu?
Rick Buczyński

Odpowiedzi:


8

Domyślam się, że ustawienie cron.php do uruchamiania co minutę spowodowało, że wiele rzeczy stoi na sobie, tzn. Nie kończy się przed wykonaniem następnego zaplanowanego zadania o tym samym charakterze lub podobnym. Ponieważ oba pliki cron.php nie byłyby świadome każdego stanu. Ten sam rekord można spróbować dwukrotnie, powodując jakiś dziwny wyjątek, który przerywa wysyłanie wiadomości e-mail w kolejce.

To powiedziawszy, są Mage::Logwyjątki w kolejce Mailer, więc upewnienie się, że rejestrowanie jest włączone, byłoby najlepszym krokiem, aby pomóc ustalić, czy są jakieś wyjątki. Rozsądnie jest też po prostu uruchomić php -f cron.phpz interfejsu CLI, aby sprawdzić, czy generuje on również wyjątki, być może nie widzisz go za kulisami.

Zacznę też od prostego mail()testu PHP, aby upewnić się, że nie masz żadnych zasad dotyczących spamu. Tylko dla pewności, że to nie jest coś niższego na stosie, co powoduje problem.

Tylko spekulacje, mam nadzieję, że to pomoże!

* EDYTOWAĆ *

Użyj cron.shzamiast cron.phpjak to zrobi, grep psaby sprawdzić, czy poprzedni proces już działa.


Dzięki za wkład, ale te problemy można z pewnością wykluczyć. To, że rzeczywiste systemowe zadanie cron działa co minutę, nie oznacza, że ​​robią to wszystkie zadania Magento cron. W naszym przypadku skonfigurowano uruchamianie tylko e-maili co minutę, a z dziennika cron Magentos możemy zobaczyć, że wszystkie zadania cron kończą się sukcesem - nawet w „stresujących” minutach (tj. Co godzinę, gdy więcej zadań działa jednocześnie, a nie tylko e-mail ). Rejestrowanie jest również włączone, a wyjątki nie są w ogóle zgłaszane. Filtrowanie spamu można wykluczyć, a także po obejściu tego problemu wszystkie e-maile docierają do wszystkich klientów.
Jey DWork

Możesz spróbować włączyć tryb programisty, aby sprawdzić, czy pomaga wygenerować wyjątki, które nie są rejestrowane. Bądź jednak ostrożny, jeśli działa w produkcji. Również jakieś skorelowane dzienniki serwera WWW?
B00MER

2
@JeyDWork, czy wdrożyłeś Aoe_Scheduler ? To może zapewnić dobrą widoczność.
zyskuje

2
Chciałbym zobaczyć aktualizację. Kolejka e-mailowa jest dla wielu wyzwaniem.
zyskuje

1
Dla mnie korzystałem ze standardu paypal, który potrzebuje zwrotu danych IPN (Instant Payment Notification) z paypal tylko po to, by potwierdzić, że płatność się powiodła i zmienić status zamówienia na przetwarzanie / ukończone i wreszcie wysłać e-mail .. ale nie miałem skonfigurowanej domeny dostęp do mojego serwera i vhostów był powodem, dla którego paypal nie mógł wysłać danych IPN do magento. Możesz sprawdzić historię IPN w profilu konta biznesowego PayPal. Paypal faktycznie pokazał dane, które miały zostać wysłane, a status to „ponawianie”.
zaw

0

Sprawdź, czy core_email_queue i core_email_queue_recipients ma AUTO_INCREMENT. Jeśli tabela nie ma włączonej sztucznej inteligencji, nie będzie przyjmować nowych wpisów.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.