Java / JMS - Обработка количества сообщений с обработкой сценариев сбоев - PullRequest
1 голос
/ 14 декабря 2010

У меня есть требование, где я должен обработать количество сообщений. Эти сообщения будут вставлены в таблицу БД другим процессом. Все, что мне нужно сделать, это проверить наличие новых сообщений в БД и отправить их соответствующему клиенту по электронной почте или http, в зависимости от их конфигурации. Количество сообщений может составлять несколько тысяч в любой момент времени, а количество клиентов - около 1000.

Я планирую спроектировать так, как работает потребитель-производитель. Подобно тому, как поток производителей опрашивает БД на наличие новых сообщений и помещает их в очередь, а рабочие потоки читают эти сообщения и процессы.

Сначала казалось, что JMS - правильное решение для этого требования. Но я ищу, если какой-либо вариант лучше, например, ExecutorService, используя Threadpool, подходящий для этого требования, учитывая следующие сценарии.

  1. Если доставка одного сообщения не удалась, мне придется повторить попытку несколько раз, по крайней мере, в течение 24 часов.
  2. если доставка одного сообщения для клиента не удалась, все шансы на то, что доставка другого сообщения также не удастся. Поэтому я должен попытаться отправить первое сообщение перед обработкой следующего сообщения для этого клиента.

Это означает, что если у меня есть одна очередь для всех сообщений для всех клиентов, то, если одно сообщение не будет выполнено, другие не будут обработаны.

Может ли кто-нибудь подсказать мне, как лучше всего справиться с этим?

Заранее спасибо.

Ответы [ 2 ]

1 голос
/ 14 декабря 2010

Вы должны серьезно взглянуть на Apache Camel .Он обрабатывает все потоки, производит и потребляет для вас большое количество встроенных компонентов (SQL, JMS, SMTP, HTTP, File и т. Д.), А ваша терминология в отношении потребителей / производителей соответствует представлению Camel об интеграции.

Реализовать что-то, как вы описываете, так же просто, как:

from("sql:select * from table")
  .to("jms:myQueue");

Взгляните на список конечных точек

0 голосов
/ 14 декабря 2010

Логика повторов относительно проста в реализации с помощью универсальной JMS: нет транзакций, присвойте сообщению атрибут повторения, увеличивайте его при каждой повторной попытке, делайте паузу в слушателе при повторной попытке, выходите после того, как лимит исчерпан.

Очередь для каждого клиента - самая простая конфигурация. Динамические очереди могут помочь вам с клиентами: динамически создавайте очередь и слушателя для каждого клиента.

На самом деле надежный опрос базы данных может стать для вас более сложной задачей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...