Привет.
Есть веб сервис, который принимает пачки запросов, он ложит их в очередь (in memory) и затем по одному берет и обрабатывает. Всё ок. Сейчас встал вопрос о том, что если с серваком будет что-то не так, то все пропадет и решили хранить в БД. 

Вопрос, что выбрать? Все что приходит в голову это jms или другой Message Brocker. Еще варианты? может поможет java queue executor? Может кто-то реально такую задачу делал, какие есть варики? Естетсвенно условий два, как можно проще и производительность не упала 

Вообще уже есть готовые сервисы которые выполняют описанную выше задачу. Например: Jesque (ничего не могу сказать про качество прорта на Java, я работал с оригинальным проектом на Ruby: Resque).

Сам сталкивался с этой задачей года 3 назад. Мы писали свой сервис с сохранением в MongoDB. Нам нужна была приоритизация задач, распределенное выполнение и резервирование выполняющих потоков. Найти сервис удовлетворяющий всем этим требованиям не удалось.

Это сообщение отредактировал(а) Kircul - 11.2.2015, 21:31

IMHO - jms вполне приличное решение.

два больших, очевидных минуса ms:
1- невозможно соблюсти порядок в очереди, а это очень важно в рамках таска.
2 - сами данные довольно большие, может доходить по тысячи объектов с 10 полями. Разве он справится? На сколько я помню в body можно положить только текстовую небольшую информацию.

1. Порядок решается вариантом размещения дампа времени в сообщение - кто раньше отправил, тот и прав.
2. Нормальный JMS может файлы по несколько мегабайт передавать вполне пристойно. И большое количество - это как раз нормально. У нас на таком механизме весьма нагруженные системы работают.

может я что не так понял.
https://en.wikipedia.org/wiki/Java_Message_Service

Так тут вопрос возникает - есть такое требование, чтобы с одной стороны в базу (или еще куда) укладывалось очень быстро (и желательно асинхронно), а с другой стороны, чтобы в соответствии со временем "укладывания" обрабатывалось ?

Тогда надо задачу точнее сформулировать:
Нужно ли обрабатывать запросы синхронно или их обработку можно отложить и отдельным потоком обрабатывать уже с учетом времени "укладывания" в базу.
Можно так - сначала положили с дампом времени одним потоком (через JMS), а потом другой поток делает обработку. Выбирает те, которые легли уже какое-то время назад, чтобы брать не самые свежие, которые еще могут быть перепутаны из-за задержки, а с запасом.

Топикстартер, посмотрите Hazelcast.

1. В JMS сообщения помимо текстовых могут иметь и такие типы:

MapMessage    Объект содержащий пары ключ-значение, например HashMap
BytesMessage    Поток не интерпретируемых системой байтов, двоичные данные 
StreamMessage    Потоковые данные,  читаемые последовательно
ObjectMessage    Сериализованный Java объект

Cериализация работает вполне пристойно.

2. Порядок обработки можно обеспечить легко, задав прзнак порядка, например числовой номер сообщения и код группы, а также общее количество. Все сообщения сохраняются в промежуточном хранилище до прибытия непрерывной последовательности ряда. Каждый обработчик должен проверять не получен ли полный набор и, при получении, делается окончательная обработка всех сообщений от первого до последнего в нужном порядке. 

3. При включении постоянства JMS провайдер обязан гарантировать доставку даже в случае сбоев, а это весьма недурственно.


Это сообщение отредактировал(а) mbasil - 13.3.2015, 17:02