ActiveMQ: отклонять подключения от производителей при заполнении постоянного хранилища

Я хотел бы настроить своих производителей ActiveMQ на аварийное переключение (я использую протокол Stomp), когда брокер достигает настроенного предела. Я хочу, чтобы потребители продолжали потреблять от перегруженного брокера, не ослабевая.

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

  1. Замедлять сообщения с помощью producerFlowControl="true" (заблокировав отправку)
  2. Генерировать исключения при использовании sendFailIfNoSpace="true"
  3. Ничего из вышеперечисленного, в таком случае... Я не уверен, что происходит? Возврат к управлению потоком TCP?

Не похоже, что какие-либо из этих вещей предназначены для запуска аварийного переключения производителя. Производитель будет переключаться при сбое, когда ему не удается подключиться, но, насколько я могу судить, нет, когда ему не удается отправить (например, из-за управления потоком производителя).

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

Спасибо!


person maxenglander    schedule 21.05.2013    source источник


Ответы (1)


Лучше всего использовать sendFailIfNoSpace, а лучше sendFailIfNoSpaceAfterTimeout. Это вызовет исключение для вашего клиента, который затем может попытаться повторно отправить сообщение другому брокеру на уровне приложения (хотя вы можете инкапсулировать эту логику поверх вашей библиотеки Stomp и использовать этот фасад из своего кода). Хотя, если ваша установка ActiveMQ правильно подключена, ваша нагрузка как с точки зрения производства, так и потребления должна быть более или менее равномерно распределена между вашими брокерами, поэтому эта функция может не принести вам многого.

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

person Jakub Korab    schedule 23.05.2013