Асинхронная обработка электронной почты в веб-приложении Java

Question

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

Мое веб-приложение построено с использованием реализации JPA в Spring и Hibernate.

Какой самый лучший и надежный способ для меня реализовать асинхронную обработку электронной почты в этом веб-приложении?

Я думаю о сохранении информации электронной почты в таблице базы данных, которая затем регулярно опрашивается кварцевым (http://www.opensymphony.com/quartz/) запланированным заданием на наличие обновлений), и когда оно находит новые неотправленные электронные письма, оно пытается отправить их.

Это разумный способ реализации того, что я хочу?

Спасибо.

Edit:

Самым голосуемым в ответе является оставить отправку почты в виде синхронного вызова, но мое мнение о том, что асинхронный подход может быть лучшим, вызвало то, что в настоящее время я использую GMail в качестве сервера исходящей почты (это для тестирования, пока в процессе разработки), и я испытываю 25-секундную задержку ответа от того, когда мое приложение пытается отправить электронное письмо, когда возвращается функция отправки почты. Что ты думаешь?

Answer 1

Я бы посоветовал вам не беспокоиться. Большинство MTA в стиле Unix изобрели и усовершенствовали отложенную отправку десятилетия назад, и вам не следует изобретать велосипед. Вы будете делать это плохо (по сравнению с sendmail или postfix), и вы что-то упустите. Мой лучший совет - использовать Java Mail APIS javax.mail и разрешить MTA работать с асинхронной частью.

Answer 2

Вы можете реализовать постановку в очередь вручную, используя MySQL или какой-либо другой постоянный механизм, но вы также можете использовать JMS для организации очередей. Это почти идеальный вариант для подобных ситуаций.

В этом случае я бы соблазнился, отделив почтовый компонент от основного приложения, и позволил им общаться через JMS. Основное приложение помещает сообщение в JMS, а почтовое приложение подписывается на очередь и пытается обработать сообщения.

JMS можно легко сделать постоянным (например, MySQL) с помощью конфигурации.

Преимущество разделения веб-приложения состоит в том, что вы абстрагируете механизм уведомления и могли бы в будущем реализовать, например, Google Wave или IRC или что-то еще, не касаясь вашего основного приложения.

Кто-то еще предложил использовать postfix или sendmail и позволить им обрабатывать очереди. Это также отличное решение, особенно если вы поместили postfix или sendmail на localhost и позволили ему направлять сообщения дальше. Попытайтесь настроить эту почтовую программу так, чтобы разрешалась маршрутизация только почты с локального хоста, чтобы предотвратить создание открытой почтовой программы :)

РЕДАКТИРОВАТЬ пояснил использование JMS + комментарий к локальному демону почтовой программы

Answer 3

Java EE 6 делает это проще благодаря аннотации @ Asynchronous .

Answer 4

Вполне разумно, именно для этого и создан Кварц.

Тем не менее, обратите внимание, что вам вообще не нужно планировать работу с базой данных (если только простоя сервера не является реальной проблемой). Вы можете просто запланировать задание Quartz без доступа к базе данных (простейшие примеры Quartz показывают, как).

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