Заставить EJB MessageDrivenBean работать как DefaultMessageListenerContainer (JMS, OpenMQ) - PullRequest
Новая
       5

Заставить EJB MessageDrivenBean работать как DefaultMessageListenerContainer (JMS, OpenMQ)

0 голосов
/ 30 ноября 2011

Я использую Spring DefaultMessageListenerContainer, чтобы получить некоторые динамические преимущества в установке значения MessageSelector, поскольку я использую Glassfish OpenMQ, который не настолько продвинут в этом отношении.Давайте иметь сообщение JMS.Слушатель выдает конкретную ошибку, которая означает: повторите попытку через x секунды.Он повторяет попытку с ошибкой: повторите попытку через x*y секунды, и так время увеличивается в геометрической прогрессии.Если вы не можете обработать его после z повторных попыток, считайте его ядовитым JMS-сообщением. 

DefaultMessageListenerContainer dmlc;
dmlc.stop();
dmlc.setMessageSelector(String.format("retries < %d AND retryTime <= %d", z, System.currentTimeMillis()));
dmlc.start();

Я не очень доволен этим решением, особенно когда Spring Docs выдает здесь предупреждение :-).Однако на данный момент все соответствует нашим потребностям.

Теперь у меня есть несколько потребителей сообщений EJB в различных приложениях.Некоторые из них нуждаются в таких динамических изменениях messageSelector.К сожалению, и, насколько мне известно, EJB MDB не поддерживают такие динамические «функции».Например, см. Это .

Это правильно?Есть ли обходной путь для решения EJB?Буду признателен за любую помощь.

1 Ответ

0 голосов
/ 02 декабря 2011

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

ConnectionFactory cf;
Connection connection = cf.createConnection();
session = connection.createSession(transactional, acknowledgeMode);

MessageConsumer messageConsumer = session.createConsumer(destination, "message selector");

Кроме того, вам нужно поместить этот код в то место, где он выполняется самостоятельновозможно в асинхронной задаче?Но вы бы заново изобрели колесо, поскольку Spring DMLC делает это лучше.

Я не знаю, почему вы делаете это:

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