Magento 1.9.1 Email Queue не работает / глючит - как устранить неполадки и какой патч считается лучшим?

35

Прежде всего, да, это еще один вопрос / тема об электронной почте 1.9.1. Но речь идет не о каких-либо проблемах cron (таких как эта или эта ) или о том, что новая функция очереди не используется (как эта ).

В нашем случае у нас была проблема, что очередь ( core_email_queueи core_email_queue_recipients) просто не получала бы электронных писем о новых заказах или обновлениях заказов, и, следовательно, больше писем не отправлялось для чего-либо связанного с заказом, также cron отлично работает и вручную добавляет электронные письма в очередь работает, и они отправляются.

Странно то, что в нашей тестовой среде все работало. Даже когда мы начали работать с сегодняшнего дня в первые минуты, все письма были обработаны, но через несколько минут (без каких-либо дополнительных изменений в действующей системе) больше никаких новых писем не добавлялось в очередь. Кажется, что это произошло (но я не могу сказать наверняка), когда первый клиент использовал PayPal Express, который мы не тестировали заранее: - / И действительно, мы использовали некоторые пользовательские переопределения в логике PayPal Express со старой sendNewOrderEmail()функцией. Но мы не могли заставить работать электронные письма снова, даже после того, как исправили их для использования queueNewOrderEmail().
Итак, первый вопрос: возможно ли, что старая функция вызвала некоторую несогласованность, которая «сломалась» очередь электронной почты? Или это просто большое совпадение и есть совершенно другое объяснение?

Поскольку мы не смогли найти проблему, но, разумеется, нам нужно было, чтобы письма снова работали как можно скорее, мы пошли на другое переопределение ядра. В Mage_Core_Model_Email_Template_Mailer(конечно, в копии local) мы закомментировали строку 76: ->setQueue($this->getQueue())
Это, кажется, обходит очередь, и все письма снова отправляются в старом порядке.

Однако, поскольку мы хотели бы свести к минимуму количество переопределений ядра, и мы также не можем прямо сейчас сказать, столкнемся ли мы с какими-либо другими побочными эффектами, любыми другими советами или решениями от людей с более глубоким пониманием кода magento и очередь электронной почты будет оценена.

Обновление для 1.9.2: при обновлении до 1.9.2 мы снова внимательно рассмотрели очередь электронной почты и не смогли воспроизвести проблему. Но поскольку мы до сих пор не имеем реального представления о том, в чем заключалась проблема с 1.9.1, и поскольку переопределение Mage_Core_Model_Email_Template_Mailer::send()все еще работает описанным здесь способом, мы все еще не используем очередь. Таким образом, мы надеемся, что не будем снова сталкиваться с той же проблемой через некоторое время в производстве.

tl; dr: в 1.9.1 очередь электронной почты не работает, закомментируя строку 76 в Mage_Core_Model_Email_Template_Mailerобход очереди электронной почты, и письма отправляются снова, но это не похоже на хорошее решение. Как это можно решить лучше?

email ce-1.9.1.0 cron Джи DWork
источник
1
Сколько тестовых транзакций вы выполнили по сравнению с количеством реальных транзакций, выполненных за первые несколько минут? Было ли это обновление более старой версии, а некоторые файлы отсутствуют или имеют неправильные разрешения? Как насчет exception.logили, возможно system.log, есть какие-нибудь подсказки там?
pspahn
Это было обновление с 1.9.0.1, и оно было сделано не через Connect-Manager, а из базы кода Magento, поэтому я сомневаюсь, что у нас отсутствуют файлы (мы также выполнили проверку и coreт. Д., Чтобы убедиться, что все не настроено или расширение установлено и немодифицировано и оно есть). Права доступа соответствуют старой настройке, а журналы / отчеты чистые.
Джи DWork
Cron настроен так же?
pspahn
Когда мы увидели изменение адреса электронной почты в журнале изменений, мы изменили запуск cron каждую минуту каждые 5 минут (как мы понимаем это изменение, так что в противном случае в худшем случае клиенты должны будут ждать до 5 минут для своих писем с подтверждением). В остальном изменений нет, и, как уже было сказано, мы видим, что cron работает без проблем. // edit: я, вероятно, должен добавить, что мы используем (и всегда использовали) Aoe_Scheduler, где мы также устанавливаем core_email_queue_send_allзапуск каждую минуту и ​​откуда мы видим, что он на самом деле выполняется.
Джи DWork
В четвертом квартале 2015 года у меня возникла та же проблема. Я могу подтвердить, что в таблицах очередей отсутствуют некоторые записи для некоторых заказов, что является явным признаком подтверждения сообщений об отсутствии электронных писем. К сожалению, логирование было отключено в моем случае, поэтому у меня пока нет ошибок для поиска. Узнали ли вы что-нибудь новое с тех пор, как вы изначально разместили, что может быть полезно добавить?
Рик Бучински

Ответы:

8

Я предполагаю, что настройка cron.php для запуска каждую минуту привела к тому, что многие вещи встали друг на друга, то есть не закончили до того, как выполнится следующая запланированная задача того же характера или аналогичная. Поскольку оба cron.php не будут знать о каждом состоянии. Одна и та же запись может быть предпринята дважды, что приведет к нечетному исключению, нарушающему отправку электронной почты в очереди.

С учетом вышесказанного, есть Mage::Logисключения в почтовой программе очереди, поэтому проверка того, включено ли ведение журнала, будет лучшим шагом, чтобы определить, есть ли исключения. Также может быть целесообразно просто запустить php -f cron.phpиз CLI, чтобы увидеть, вызывает ли он какие-либо исключения, вы можете не увидеть, что он работает за кулисами.

Я бы также начал с простого mail()теста PHP, чтобы убедиться, что вы не сталкиваетесь ни с какими политиками спама или чем-то подобным. Просто чтобы быть уверенным, что это не что-то меньшее в стеке, вызывающее проблему.

Просто некоторые предположения, надеюсь, это поможет!

* РЕДАКТИРОВАТЬ *

Используйте cron.shвместо , cron.phpкак он будет делать , grep psчтобы посмотреть , чтобы увидеть , если предыдущий процесс уже запущен.

B00MER
источник
Спасибо за вклад, но эти проблемы вполне могут быть исключены. То, что реальное задание системного cron выполняется каждую минуту, не означает, что все задания cron Magento выполняются. В нашем случае только электронная почта была настроена так, что она также запускается каждую минуту, и из журнала cron Magentos мы видим, что все задания cron завершаются успешно - даже в «напряженные» минуты (т.е. каждый час или около того, когда одновременно запускается больше заданий, а не только электронная почта). ). Ведение журнала также включено, и исключения не генерируются вообще. Использование спам-фильтров может быть исключено, так как после обходного пути, который я разместил, все электронные письма достигают всех клиентов.
Jey DWork
Вы можете попробовать включить режим разработчика, чтобы увидеть, помогает ли он генерировать исключения, которые не регистрируются. Будьте осторожны, если он запущен в производство. Также какие-либо коррелирующие журналы веб-сервера?
B00MER
2
@JeyDWork вы реализовали Aoe_Scheduler ? Это может дать хорошую видимость.
отметки
2
Хотелось бы увидеть обновление. Очередь электронной почты становится проблемой для многих.
отметки
1
Для меня я использовал стандарт PayPal, который требует возврата данных IPN (мгновенного платежа) из PayPal только для того, чтобы подтвердить, что платеж был успешным, изменить статус заказа на обработку / завершен и, наконец, отправить электронное письмо ..., но у меня не было фактической настройки домена для моего сервера и доступа к vhosts это было причиной, по которой PayPal не мог публиковать данные IPN в magento. Вы можете проверить историю IPN в профиле бизнес-аккаунта PayPal. Paypal фактически показал данные, которые предполагалось отправить, и статус был «повторная попытка» ..
Zaw
0

Проверьте, имеют ли core_email_queue и core_email_queue_recipients AUTO_INCREMENT. Если в этой таблице нет AI, она не будет принимать новые записи.

Али Экзальтер
источник