我们的 CF 服务器偶尔会停止处理邮件。 这是有问题的,因为我们的许多客户都依赖它。
我们在网上发现了一些建议,其中提到了无法传递的文件夹中的零字节文件,因此我创建了一个每三分钟删除它们的任务。 然而,停工再次发生。
我正在寻找诊断和解决此问题的建议。
添加:
- 队列失败时邮件日志中没有错误
- 由于我们发送的邮件量很大,我们还没有尝试在不使用队列的情况下运行此
添加 2:
- 似乎没有假脱机文件夹中的任何文件有问题。 当我们重新启动邮件队列时,它们似乎都正确处理。
补充 3:
Our CF server occasionally stops processing mail. This is problematic, as many of our clients depend on it.
We found suggestions online that mention zero-byte files in the undeliverable folder, so I created a task that removes them every three minutes. However, the stoppage has occurred again.
I am looking for suggestions for diagnosing and fixing this issue.
Added:
- There are no errors in the mail log at the time the queue fails
- We have not tried to run this without using the queue, due to the large amount of mail we send
Added 2:
- It does not seem to be a problem with any of the files in the spool folder. When we restart the mail queue, they all seem to process correctly.
Added 3:
- We are not using attachments.
发布评论
评论(7)
我有时会遇到同样的问题,这不是由于零字节文件造成的,尽管这个问题过去确实出现过。 似乎一两个文件(文件夹中最旧的文件)将使队列无法处理。 我所做的是将所有邮件移至保留文件夹,重新启动邮件队列,并按时间倒序一次将邮件复制回一大块,等待它们出去并再移动一些邮件。 阻塞队列的消息被放入一个单独的文件夹中,以便稍后检查。
您可以通过停止队列以编程方式执行此操作,将最旧的文件移动到另一个文件夹,然后启动邮件队列并通过检查文件夹文件计数和日期来查看发送是否成功开始。 如果删除最旧的文件不起作用,请重复前面的过程,直到所有有问题的邮件文件都被移动并继续成功发送。
我希望有帮助。
I have the same problem sometimes and it isn't due to a zero byte file though that problem did crop up in the past. It seems like one or two files (the oldest ones in the folder) will keep the queue from processing. What I do is move all of the messages to a holding folder, restart the mail queue and copy the messages back in a chunk at a time in reverse chronological order, wait for them to go out and move some more over. The messages which were holding up the queue are put in a separate folder to be examined latter.
You can probably programmatically do this by stopping the queue, moving the oldest file to another folder, then start the mail queue and see if sending begins successfully by checking folder file counts and dates. If removing the oldest file doesn't work, repeat the previous process until all of the offending mail files are moved and sending continues successfully.
I hope the helps.
您是否尝试过完全绕过队列? (在 CF 管理中,在“邮件假脱机设置”下,取消选中“假脱机邮件以便传送”。)
Have you tried just bypassing the queue altogether? (In CF Admin, under Mail Spool settings, uncheck "Spool mail messages for delivery.")
Ben Doom 的代码中有一个错误。 不管怎样,谢谢你,本,代码很棒,我们现在在一台安装了 CF8 的服务器上使用它,但是:
如果目录 (\spool) 为空,则代码失败(错误:传递给日期函数 DateDiff 的日期值未指定或无效。)这是因为如果查询对象 spool 为空 (spool.recordcount EQ 0),则 datediff 函数会生成一个错误。
我们现在使用这个:
There is a bug in Ben Doom's code. Thank you anyway ben, the code is great, and we use it now on one of our servers with CF8 installed, but:
if directory (\spool) is empty, the code fails (error: Date value passed to date function DateDiff is unspecified or invalid.) That's because if the query object spool is empty (spool.recordcount EQ 0), the datediff function produces an error.
we used this now:
我们实际上有一个相同的设置,Win2K3 上的 32 位 CF8。
大约一年前,我们采用了 Ben 的解决方案,该解决方案有助于自动重新排队陷入困境的电子邮件。
然而最近,由于没有特殊原因,我们的 7 个网络服务器之一决定在每次尝试发送电子邮件时都进入这种状态。
我们的每一个网络服务器都是彼此相同的克隆,所以为什么只发生在那个服务器上是很奇怪的。
另一件需要注意的事情是,由于 JRUN 的内存管理问题,我们有一个脚本会在半夜重新启动机器。 重新启动的行为似乎引发了问题。 随后重新启动 CF 服务将清除它,并且机器将正常工作,直到再次重新启动。
我们发现问题与McAfee病毒扫描程序有关,更新排除c:\ColdFusion8目录后,问题消失了。
希望有帮助。
We have actually an identical setup, 32bit CF8 on Win2K3.
We employed Ben's solution about a year ago, and that certain has helped auto re-queue emails that get stuck.
However recently for no particular reason one of our 7 web servers decided to get into this state with every email attempt.
Each of our web servers are identical clones of each other, so why it was only happening to that one is bizarre.
Another item to note is that we had a script which reboot the machine in the middle of the night due to JRUN's memory management issues. The act of rebooting seemed to initiate the problem. A subsequent restarting of the CF service would then clear it, and the machine would be fine until it rebooted again.
We found that the problem is related to the McAfee virus scanner, after updating it to exclude the c:\ColdFusion8 directory, the problem went away.
Hope that helps.
CFMX 8 中的邮件后台处理程序和带有附件的消息存在问题,已通过修补程序之一修复。 至少 8.0.1 版本应该已经修复了这个问题。
There is/was an issue with the mail spooler and messages with attachments in CFMX 8 that was fixed with one of the Hotfixes. Version 8.0.1, at least, should have had that fixed.
我们最终做了什么:
我写了两个计划任务。 第一个检查队列文件夹中是否有任何早于 n 分钟(当前设置为 30)的消息。 第二个在每晚使用率较低时重置队列。
不幸的是,我们从未真正发现为什么队列会脱轨,但这似乎只在我们使用 Exchange 时才会发生——我们尝试过的其他邮件服务器没有这个问题。
编辑:我被要求发布我的代码,所以这是在发现旧邮件时重新启动的代码:
What we ended up doing:
I wrote two scheduled tasks. The first checked to see if there were any messages in the queue folder older than n minues (currently set to 30). The second reset the queue every night during low usage.
Unfortunately, we never really discovered why the queue would come off the rails, but it only seems to happen when we use Exchange -- other mail servers we've tried do not have this issue.
Edit: I was asked to post my code, so here's the one to restart when old mail is found:
无论如何,您尝试过关闭假脱机功能吗? 我见过邮件以半秒内 500-600 条消息的速度发送,而且这是在一个蹩脚的服务器上发送的。 如果标准页面超时时间为 60 秒,那么在页面超时之前您可以发送约 72,000 封电子邮件。 您一次发送的数量是否超过 72,000 个?
我在 CFMail 之前使用的另一种方法是构建一个自定义后台处理程序,速度如此之快。 不要即时发送电子邮件,而是将它们保存到数据库表中。 然后设置一个计划作业来发送数百条消息,并在几分钟后自行重新安排,直到表为空。
我们安排该作业每天运行一次; 如果表不为空,它可以重新安排自己在几分钟内再次运行。 从来没有遇到过问题。
Regardless, have you tried turning off spooling? I've seen mail get sent at a rate of 500-600 messages in a half second, and that's on kind of a crappy server. With the standard page timeout at 60 seconds, that would be ~72,000 emails you could send before the page would time out. Are you sending more than 72,000 at a time?
An alternative I used before CFMail was this fast was to build a custom spooler. Instead of sending the emails on the fly, save them to a database table. Then setup a scheduled job to send a few hundred of the messages and reschedule itself for a few minutes later, until the table is empty.
We scheduled the job to run once a day; and it can re-schedule itself to run again in a couple of minutes if the table isn't empty. Never had a problem with it.