Мне было предложено разработать и внедрить систему для получения большого объема автоматизированных данных датчиков с большого количества устройств. Эти данные будут создаваться через регулярные промежутки времени и отправляться на сервер в виде xml в сообщении http. Устройства будут пересылать одни и те же данные, если они не получат определенное подтверждение от сервера. Некоторая потенциально тяжелая обработка этих данных должна произойти до того, как она будет вставлена в несколько таблиц в основной базе данных через транзакцию, и, кроме того, некоторые точки данных должны быть выделены для перенаправления на другие внешние URL-адреса.
Я планирую использовать сервер приложений Java (опираясь на GlassFish) с сервлетом для приема входящих данных. Я хотел бы реализовать какой-то механизм очередей для временного хранения данных, чтобы ответ обратно на датчик не зависел от всей промежуточной обработки. Отдельные независимые очереди также являются требованием для части реверсирования данных. После выполнения некоторых исследований два основных варианта:
1) Установите базу данных на сервере приложений и используйте таблицы для различных очередей. Очереди будут обрабатываться Java-приложением, либо запущенным на сервере приложений, либо автономным, так как он является собственной службой.
2) Используйте JMS-решение, поддерживающее базу данных, для реализации очереди.
Я не знаком с JMS, но из того, что я прочитал, похоже, это лучшее решение в этом случае. Основным требованием является то, что никакие данные датчика никогда не теряются или не выпадают из очереди перед обработкой и что они будут обрабатываться более или менее последовательно. Мы также хотели бы упростить процесс обработки некоторых очередей в определенное время, но при этом они накапливают данные, и эти сообщения никогда не истекают автоматически.
Со стратегией 1 мне очевидно, как удовлетворить эти требования, но она может быть менее надежной и масштабируемой и сложнее разрабатывать, чем стратегия 2, так как мне нужно будет написать свой собственный многопоточный код для обработки различных независимые очереди. Мне интересно, какие потенциальные ловушки могут быть в использовании JMS-очередей для этой цели, так как я никогда с ними не работал.
Целостность данных - большая проблема, поэтому мне нужно убедиться, что JMS не гарантирует потери данных в случае перезагрузки сервера, отключения питания или если по какой-то причине очередь становится очень большой. Например, может возникнуть проблема с завершением транзакций в основной базе данных в течение определенного периода времени, что может привести к тому, что JVM закончит работу с памятью, сбой и потеряет все накопленные данные? (Это будет сценарий кошмара).
Кроме того, мне было интересно, будет ли какой-либо способ приостановить обработку очереди JMS с помощью администратора приложения для сервера приложений или легко увидеть, что в очереди (я бы включил объект, который будет представлять собой сообщение xml плюс некоторые другие данные, включая полученную временную метку и т.д.). Я прочитал несколько сообщений, посвященных связанным с ними вопросам, но хотел получить прямую обратную связь. В основном я хотел бы знать примеры (если они есть), где JMS не является подходящим решением для очередей и если это один из этих случаев. Любые советы приветствуются.