Вызов медленного обслуживания через HTTP из компонента, управляемого сообщениями (MDB) - PullRequest
Новая
       56

Вызов медленного обслуживания через HTTP из компонента, управляемого сообщениями (MDB)

2 голосов
/ 03 октября 2011

У меня есть компонент, управляемый сообщениями, который обслуживает сообщения следующим образом: 1. Он получает данные из входящего сообщения.2. Вызывает внешнюю службу через HTTP (буквально, отправляет запросы GET с использованием HttpURLConnection), используя данные из шага 1. Независимо от того, сколько времени занимает вызов - сообщение НЕ ДОЛЖНО быть отброшено.3. Использует результат шага 2 для сохранения данных (с использованием объектных компонентов).

Скорость входящих сообщений: I. В большинстве случаев низкая: порядка единиц / десятков в день.II.Иногда высокий: порядка сотен за несколько минут.

ВОПРОС: Использование этого сервиса на шаге (2) является относительно медленным (20 секунд на запрос и ухудшается при увеличении рабочей нагрузки), что является лучшим способом решенияСитуация II?

ЧТО Я ПОПЫТАЛ: 1. Позволить MDB ждать, пока служба не будет выполнена, независимо от того, сколько времени это займет.Это приводит к откату транзакций MDB по таймауту и ​​повторной доставке сообщений, что увеличивает рабочую нагрузку и делает ситуацию еще хуже.2. Установка таймаута для HttpURLConnection дает некоторые гарантии с точки зрения времени завершения метода MDB onMessage (), но оставляет открытым вопрос: как поступить с сообщениями «timed out».

Любые идеи очень приветствуются.Спасибо!

Ответы [ 2 ]

0 голосов
/ 04 октября 2011

На этом я остановился (в основном это конфигурация сервера приложений):

  1. Относительно короткий (по сравнению с таймаутом транзакции) тайм-аут для HTTP-вызова.Обоснование: длительные транзакции из моего опыта, как правило, имеют неблагоприятные побочные эффекты, такие как «зависание» приложений от потоков.точка зрения сервера или дополнительное внимание к конфигурации базы данных и т. д.
    Я выбрал 80 секунд в качестве значения тайм-аута.
  2. Увеличен интервал повторной доставки до нескольких минут для неудачных сообщений.
  3. Тщательная регулировка количества потоков, которые обрабатывают сообщения одновременно.Я сбалансировал это значение с пропускной способностью службы HTTP.
0 голосов
/ 03 октября 2011

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

...