Magento 1.9.1电子邮件队列不起作用/不正常-如何进行故障排除以及什么是最佳补丁?


35

首先,这是关于1.9.1电子邮件队列的又一个问题/主题。但这与任何cron问题(如thisthis)或未使用的新队列功能(如this)无关。

在我们的案例中,我们遇到了一个问题,即队列(core_email_queuecore_email_queue_recipients)根本不会收到任何有关新订单或订单更新的电子邮件,因此,不再有任何与订单相关的电子邮件被发送出去,而且cron的运行状况很好,并且手动将电子邮件添加到队列工作,他们被发送出去。

奇怪的是,在我们的测试环境中,一切正常。即使今天我们在开始的第一分钟上线了所有电子邮件,但过了几分钟(当然,在实时系统上没有任何进一步的修改),根本没有更多的新电子邮件添加到队列中。当第一个客户使用PayPal Express时,似乎发生了这种情况(但我不能确定),我们之前没有进行过测试:-/实际上,我们在使用旧sendNewOrderEmail()功能的PayPal Express逻辑中使用了一些自定义替代。但是即使修补了使用的电子邮件,我们也无法使电子邮件重新工作queueNewOrderEmail()
因此,第一个问题是,旧功能是否可能引发了一些不一致,从而导致“中断” 电子邮件队列?还是所有这只是一个偶然的巧合,并且有完全不同的解释?

由于我们找不到问题,但是当然需要尽快重新使用电子邮件,因此我们进行了另一个核心替代。在Mage_Core_Model_Email_Template_Mailer(当然是in的副本中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绕过电子邮件队列,并且再次发送了邮件,但这并不是一个好的解决方案。如何更好地解决呢?


1
与前几分钟进行了多少笔实时交易相比,您运行了多少笔测试交易?这是从旧版本进行的升级,是否缺少某些文件或权限不正确?如何exception.log或可能system.log,有什么线索吗?
pspahn 2014年

它是从1.9.0.1升级而来,不是通过Connect-Manager完成的,而是从Magento代码库完成的,因此,我怀疑我们缺少文件(我们也进行了差异化处理,core以确保所有未定制的内容或扩展都已存在,并且未经修改,它是)。权限与旧设置匹配,日志/报告干净。
Jey DWork 2014年

cron设置相同吗?
pspahn 2014年

当我们在更改日志中看到电子邮件更改时,我们将cron更改为每5分钟之前每分钟运行一次(因为我们了解更改,因此在最坏的情况下,客户将不得不等待5分钟才能收到确认邮件)。除此之外,没有任何变化,并且如前所述,从其他工作中我们可以看到cron运行没有问题。// edit:我可能应该补充一点,我们使用(并且一直使用)Aoe_Scheduler,设置core_email_queue_send_all为每分钟运行一次,并从中看到它实际上已执行。
Jey DWork 2014年

2015年第4季度,我遇到了同样的问题,我可以确认队列表完全缺少某些订单的条目,这是清楚的信号,以确认未收到电子邮件的报告。不幸的是,就我而言,日志记录已关闭,因此我没有错误要查找。自从您最初发布以来,您是否学过新知识,可能会有所帮助?
里克·布钦斯基

Answers:


8

我的猜测是,将cron.php设置为每分钟运行一次,导致很多事情相互重叠,即在执行相同或相似性质的下一个任务之前尚未完成。由于两个cron.php都不知道每个状态。可能会尝试两次相同的记录,从而导致某些奇怪的异常破坏了电子邮件发送的队列。

如此说来Mage::Log,队列邮件程序就有例外,因此确保启用日志记录将是帮助确定是否存在任何例外的最佳步骤。最好php -f cron.php仅从CLI 运行,以查看它是否还会引发任何异常,这可能是明智的,您可能看不到它在后台运行。

我也将从一个简单的PHP mail()测试开始,以确保您没有遇到任何垃圾邮件策略或类似策略。只是要确保它不是导致问题的堆栈中较低的东西。

只是一些猜测,希望对您有所帮助!

*编辑*

使用cron.sh的,而不是cron.php因为它会做grep ps一下,看看以前的进程已经运行。


感谢您的输入,但是可以肯定地排除了这些问题。仅仅因为实际的系统cron作业每分钟运行并不意味着所有Magento cron作业都可以。在我们的案例中,仅将电子邮件设置为每分钟也运行一次,从Magentos cron日志中,我们可以看到所有cron作业均成功完成-即使在“压力很大”的分钟内(即每小时一次或更多,一次运行更多作业而不仅仅是电子邮件) )。还启用了日志记录,并且根本不会引发异常。在我发布所有解决方法后,可以排除运行垃圾邮件过滤器的可能性,也可以排除在所有客户之后。
杰伊·德沃克(Jey DWork)2015年

您可能想要尝试启用开发人员模式,以查看它是否有助于生成任何未记录的异常。但是,如果它在生产中运行,请小心。还有任何相关的Web服务器日志吗?
B00MER 2015年

2
@JeyDWork您实现了Aoe_Scheduler吗?这样可以提供良好的可见性。
Benmarks 2015年

2
希望看到更新。事实证明,电子邮件队列对许多人来说都是一个挑战。
Benmarks 2015年

1
对我来说,我使用的是贝宝(Paypal)标准,该标准需要从贝宝(Paypal)返回IPN(即时付款通知)数据,只是为了确认付款是否成功,并将订单状态更改为“处理中/已完成”,最后发送电子邮件..但我没有设置实际域供我的服务器和虚拟主机访问,这是paypal无法将IPN数据发布到magento的原因。您可以在贝宝业务帐户配置文件中查看IPN历史记录。贝宝实际上表明是假设送出去的数据和状态是“重试” ..
ZAW

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.