Mercury Pressflow (drupal) 上的重复电子邮件通知
我们在使用 Mercury Pressflow 实施上的通知模块向用户发送重复通知时遇到了问题。除了一件事之外，重复的消息是相同的 - 其中一条消息中的 [node-url] 标记被替换为“默认”。消息中的所有其他标记均已正确替换。
重复的电子邮件不会持续发生，可能占已发送通知的 10-15%，但是重复的邮件始终具有正确的 URL 和地址。 “默认”网址。
我们对 Mercury 所做的唯一重大修改是将 MySQL 剥离到它自己的服务器上并添加复制。目前，我们将读取设置为 2 个 MySQL 实例之间的循环。
我根据发现的类似问题进行了以下故障排除 确保 cron 作业调用正确的 url 将所有名为“default”的配置替换为站点名称（Memcached、Varnish 和 Apache 配置） 在通知模块的 init_hook 中禁用缓存
有没有人经历过与通知和 Mercury 类似的事情？非常感谢任何和所有的建议。
We’re running into an issue sending duplicate notifications to our users using the Notifications module on our Mercury Pressflow implementation. The duplicate messages are identical save one thing- the [node-url] token is being replaced with ‘default’ in one of the messages. All the other tokens in the message are being replaced correctly.
The duplicate emails do not happen consistently, maybe 10-15% of the notifications sent out, however a duplicate message always has the proper url & the ‘default’ url.
The only major modification we’ve made to Mercury was spinning off MySQL to it’s own server and adding replication. We currently have the reads set up to round robin between the 2 MySQL instances.
I have done the following troubleshooting based on finding similar issues
made sure the cron job is calling the correct url
replaced all configurations named ‘default’ with the site name (Memcached, Varnish, and Apache configs)
disabled caching in an init_hook in the notifications module
Has anyone out there experienced anything similar with Notifications and Mercury? Any and all advice is greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“Mercury”堆栈位于 Drupal 外部，不会影响电子邮件的排队或发送方式。您的消息传递/通知配置或使用中的某些内容导致创建多条消息。
如果您在这里有任何自定义代码，我会查看它并尝试跟踪令牌差异。
The "Mercury" stack is external to Drupal and doesn't affect how email is queued or sent. Something within your messaging/notifications configuration or use is causing multiple messages to be created.
If you have any custom code here, I would look at that and try to trace the token variance.