Наш CF-сервер иногда перестает обрабатывать почту. Это проблематично, так как от этого зависят многие наши клиенты.
Мы нашли в Интернете предложения, в которых упоминаются файлы с нулевым байтом в недоставленной папке, поэтому я создал задачу, которая удаляет их каждые три минуты. Однако остановка произошла снова.
Я ищу предложения по диагностике и устранению этой проблемы.
Добавлен:
Добавлено 2:
Добавлено 3:





Вы пробовали вообще просто обойти очередь? (В CF Admin в настройках спула почты снимите отметку с «Спулинга почтовых сообщений для доставки».)
Иногда у меня возникает такая же проблема, и это не из-за файла с нулевым байтом, хотя эта проблема возникала в прошлом. Кажется, что один или два файла (самые старые в папке) не будут обрабатывать очередь. Что я делаю, так это перемещаю все сообщения в папку хранения, перезапускаю почтовую очередь и копирую сообщения обратно по частям в обратном хронологическом порядке, жду, пока они исчезнут, и перемещаюсь еще раз. Сообщения, находившиеся в очереди, помещаются в отдельную папку для последующего изучения.
Вы, вероятно, можете сделать это программно с помощью остановка очереди, переместив самый старый файл в другую папку, затем запустить почтовую очередь и посмотреть, успешно ли началась отправка, проверив количество и дату файлов в папке. Если удаление самого старого файла не сработало, повторяйте предыдущий процесс, пока все почтовые файлы с нарушением не будут перемещены и отправка не будет продолжена успешно.
Надеюсь, это поможет.
В CFMX 8 есть / была проблема с диспетчером очереди почты и сообщениями с вложениями, которая была исправлена с помощью одного из исправлений. По крайней мере, в версии 8.0.1 это должно было быть исправлено.
We have not tried to run this without using the queue, due to the large amount of mail we send
Тем не менее, вы пытался отключили спулинг? Я видел, как почта отправлялась со скоростью 500-600 сообщений за полсекунды, и это на каком-то паршивом сервере. При стандартном тайм-ауте страницы в 60 секунд это будет ~ 72 000 писем, которые вы могли бы отправить до того, как страница истечет. Вы отправляете более 72000 единиц за раз?
Альтернативой, которую я использовал до того, как CFMail стал настолько быстрым, было создание специального диспетчера очереди печати. Вместо того, чтобы отправлять электронные письма на лету, сохраните их в таблице базы данных. Затем настройте запланированное задание, чтобы отправить несколько сотен сообщений и перенести его на несколько минут позже, пока таблица не станет пустой.
Мы запланировали выполнение задания один раз в день; и он может перепланировать себя для повторного запуска через пару минут, если таблица не пуста. Никогда не было проблем с этим.
Что мы в итоге сделали:
Я написал две задачи по расписанию. Первый проверил, есть ли в папке очереди сообщения старше п минут (в настоящее время установлено 30). Второй сбрасывает очередь каждую ночь во время низкого использования.
К сожалению, мы так и не узнали, почему очередь сошла с рельсов, но кажется, что это происходит только тогда, когда мы используем Exchange - другие почтовые серверы, которые мы опробовали, не имеют этой проблемы.
Редактировать: Меня попросили опубликовать мой код, поэтому вот тот, который нужно перезапустить, когда будет обнаружена старая почта:
<cfdirectory action = "list" directory = "c:\coldfusion8\mail\spool\" name = "spool" sort = "datelastmodified">
<cfset restart = 0>
<cfif datediff('n', spool.datelastmodified, now()) gt 30>
<cfset restart = 1>
</cfif>
<cfif restart>
<cfset sFactory = CreateObject("java","coldfusion.server.ServiceFactory")>
<cfset MailSpoolService = sFactory.mailSpoolService>
<cfset MailSpoolService.stop()>
<cfset MailSpoolService.start()>
</cfif>
У нас возникла та же проблема, но остановка и запуск MailSpoolService, как описано здесь, не влияет на проблему - все, что у нас работает, - это перезапуск Coldfusion. Есть ли у кого-нибудь другие предложения, которые избавят нас от необходимости перезапускать Coldfusion?
@Loftx - Какой почтовый сервер вы используете? Мы столкнулись с этой проблемой только тогда, когда силы, которые заставили нас использовать Exchange. Можно ли использовать небольшую систему ретрансляции SMTP? Бесплатная версия MailEnable отлично подходит для этого в нашей производственной среде.
мы используем SMTP-сервер, поставляемый с IIS в Windows Server 2003. Сервер работал нормально в течение нескольких лет, а затем у нас возникла эта проблема, возможно, 4 раза за последние 6 месяцев или около того. Если хотите, я могу начать новый вопрос, а не продолжать этот.
Я не против, чтобы вы здесь комментировали. Однако я был бы обеспокоен, что вы не увидите новых ответов. Возможно, это другая проблема. Я видел 4 капли за день.
Увидел это сегодня в CF10. Код stop () и start () в этом ответе сработал. Очевидно, эта ошибка и обходной путь будут жить вечно.
Фактически, теперь это может привести к новой ошибке. CF10, W2K8. Мы используем это по ночам, потому что время от времени очередь прекращает обработку. Теперь мы получаем дубликаты писем и, вероятно, сейчас работают 2 копии диспетчера очереди.
Фактически у нас есть идентичная установка, 32-битный CF8 на Win2K3.
Мы использовали решение Бена около года назад, и это определенно помогло автоматически переставлять в очередь застрявшие электронные письма.
Однако недавно без особой причины один из наших 7 веб-серверов решал переходить в это состояние при каждой попытке электронной почты.
An exception occurred when setting up mail server parameters. This exception was caused by: coldfusion.mail.MailSessionException: An exception occurred when setting up mail server parameters..
Все наши веб-серверы являются идентичными клонами друг друга, поэтому странно, почему это происходило только с этим сервером.
Также следует отметить, что у нас был сценарий, который перезагружал машину посреди ночи из-за проблем с управлением памятью JRUN. Акт перезагрузки, казалось, инициировал проблему. Последующий перезапуск службы CF очистит ее, и машина будет в порядке, пока не перезагрузится снова.
Мы обнаружили, что проблема связана с антивирусным сканером McAfee, после его обновления, чтобы исключить каталог c: \ ColdFusion8, проблема исчезла.
Надеюсь, это поможет.
В коде Бена Дума есть ошибка. В любом случае спасибо, Бен, код отличный, и сейчас мы используем его на одном из наших серверов с установленным CF8, но: если каталог (\ spool) пуст, код не работает (ошибка: значение даты, переданное в функцию date DateDiff, не указано или недействительно). Это потому, что, если спул объекта запроса пуст (spool.recordcount EQ 0), функция dateiff выдает сообщение ошибка.
мы использовали это сейчас:
<!--- check if request for this page is local to prevent "webusers" to request this page over and over, only localhost (server) can get it e.g. by cf scheduled tasks--->
<cfsetting requesttimeout = "30000">
<cfset who = CGI.SERVER_NAME>
<cfif find("localhost",who) LT 1>
security restriction, access denied.
<cfabort>
</cfif>
<!--- get spool directory info --->
<cfdirectory action = "list" directory = "C:\JRun4\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\Mail\Spool\" name = "spool" sort = "datelastmodified">
<cfset restart = 0>
<cfif spool.recordcount GT 0><!--- content there? --->
<cfif datediff('n', spool.datelastmodified, now()) gt 120>
<cfset restart = 1>
</cfif>
</cfif>
<cfif restart><!--- restart --->
<cfsavecontent variable = "liste">
<cfdump var = "#list#">
</cfsavecontent>
<!--- info --->
<cfmail to = "[email protected]" subject = "cfmailqueue restarted by daemon" server = "xxx" port = "25" from = "xxxx" username = "xxxx" password = "xxx" replyto = "xxxx">
1/2 action: ...try to restart. Send another mail if succeeded!
#now()#
Mails:
#liste#
</cfmail>
<cfset sFactory = CreateObject("java","coldfusion.server.ServiceFactory")>
<cfset MailSpoolService = sFactory.mailSpoolService>
<cfset MailSpoolService.stop()>
<cfset MailSpoolService.start()>
<!--- info --->
<cfmail to = "[email protected]" subject = "cfmailqueue restarted by daemon" server = "xxx" port = "25" from = "xxxx" username = "xxxx" password = "xxx" replyto = "xxxx">
2/2 action: ...succeeded!
#now()#
</cfmail>
</cfif>
Раньше у меня это происходило периодически, и мне нравились странные «<.» проблема, мы так и не определили причину ... мы могли отправить 100 одинаковых писем, и 35-е задохнулось ... удаление самого старого, универсально исправленное ... настройка процедуры для мониторинга, которая является прекрасным решением для этих странных незарегистрированных jrun икота.