Альтернатива JMS? что-то для отделения отправки писем от http reqs

Question

у нас есть веб-приложение, которое выполняет различные действия и иногда отправляет электронные письма пользователям в зависимости от того или иного действия. Я хочу отделить потоки HTTP-запросов от фактической отправки электронной почты на случай, если возникнут какие-либо проблемы с SMTP-сервером или отставанием. В прошлом я использовал для этого JMS и у меня не было с этим проблем. Однако в данный момент для веб-приложения, которое мы делаем, JMS сейчас чувствует себя немного переубежденным (с точки зрения настройки и т. Д.), И мне было интересно, какие еще есть альтернативы. В идеале мне просто нравится что-то, что я могу запустить в процессе (JVM / Tomcat), но когда контекст сервлета выгружен, все ожидающие элементы в очереди будут заменены на disk / db. Конечно, я мог бы просто что-то кодировать вместе, используя в памяти Q, но я стремлюсь получить выгоду от проектов с открытым исходным кодом, поэтому задаюсь вопросом, что там будет, если что-нибудь.

Если JMS действительно является ответом, кто-нибудь знает что-то, что может соответствовать нашим простым требованиям. спасибо

Answer 1

Я думаю, что весенняя интеграция будет работать и в этом случае.

http://www.springsource.org/spring-integration

Answer 2

Ух ты, эта проблема часто возникает. CommonJ WorkManagager - это то, что вы ищете. Реализацию Tomcat можно найти здесь . Он позволяет безопасно создавать потоки в среде Java EE, но гораздо легче, чем при использовании JMS (что, очевидно, будет работать).

Answer 3

Я использую JMS для чего-то подобного. Наши причины использования JMS:

• У нас уже был JMS-сервер для чего-то другого (поэтому он просто добавлял новую очередь)
• Мы хотели, чтобы наше приложение было отделено от процесса обработки, поэтому ошибки с обеих сторон останутся на их стороне
• Приложение может поместить сообщение в очередь, зафиксировать и продолжить. Не нужно беспокоиться о том, как сохранить сообщения, как начать заново после сбоя и т. Д. JMS сделает все это за вас.

Answer 4

Помимо JMS, для коротких сообщений вы также можете использовать Amazon Simple Queue Service (SQS). Хотя вы также можете считать это излишним, учтите тот факт, что требуется минимальное техническое обслуживание, оно хорошо масштабируется, имеет сверхвысокую доступность и не стоит слишком много. Нет затрат на создание новых очередей и т. Д .; или имея учетную запись. Насколько я помню, он основан исключительно на количестве операций, которые вы выполняете (отправка сообщений, опрос / получение).

Основным ограничением на самом деле является размер сообщения (есть и другие, например, не гарантирующее упорядочение из-за распределенного характера и т. Д.); но это может работать как есть. Или для больших сообщений, используя сервис AWS s3, для хранения реального тела и просто передавая заголовки через SQS.

Answer 5

Вы можете использовать планировщик. Посмотрите на Кварц .

Идея состоит в том, что вы планируете запуск задания с регулярными интервалами. Все запросы должны быть сохранены где-то. Запланированная работа прочитает их и обработает их. Вам необходимо определить интервал между двумя последующими заданиями в соответствии с вашими потребностями.

Это рекомендуемый способ ведения дел. Полноценные серверы приложений предлагают для этого таймеры Java EE, но их нет в Tomcat. Кварц хорош, и вы можете избежать запуска собственных потоков, что в некоторых ситуациях может привести к путанице (например, в обновлениях приложений).

Answer 6

Поскольку вы говорите, что приложение «иногда» отправляет электронные письма пользователям, это не похоже на то, что вы говорите о большом объеме почты. Быстрое и грязное решение было бы просто Runtime.getRuntime().exec():

sendmail recipient@domain.com

и выведите сообщение в результирующий процесс getOutputStream (). После этого это проблема sendmail.

Приведите цифру в минуту, чтобы увидеть, есть ли у вас sendmail на сервере, около пятнадцати минут, чтобы собрать тест, если вы это сделаете, и ничего не установить, если вы нашли sendmail. Еще несколько минут, чтобы правильно построить заголовки писем (просто - , вот несколько примеров ), и все готово.

Надеюсь, это поможет ...

Answer 7

Я согласен, что JMS излишне для этого.

Вы можете просто отправить электронное письмо в отдельном потоке (т.е. отдельно от потока обработки запросов). Единственное, о чем следует быть осторожным, это то, что если ваше приложение вообще получает какой-либо трафик, вы можете использовать пул потоков, чтобы избежать проблем с истощением ресурсов. В пакете java.util.concurrent есть несколько полезных вещей для пулов потоков.