Очередь JMS заполнена

Приложение Java EE отправляет JMS в очередь, но иногда потребительское приложение JMS перестало получать JMS. Это приводит к тому, что очередь JMS очень большая, даже полная, что разрушает сервер. Мой сервер - JBoss или Websphere. Предоставляют ли серверы приложений стратегию удаления сообщений "время ожидания" JMS?

Что такое стратегия для обработки большой очереди JMS? Спасибо!

ОТВЕТЫ

Ответ 1

При любом асинхронном обмене сообщениями вы должны иметь дело с проблемой "быстрый производитель/медленный потребитель". Есть несколько способов справиться с этим.

  • Добавить потребителей. С помощью WebSphere MQ вы можете запускать очередь на основе глубины. Некоторые магазины используют это, чтобы добавить новые экземпляры клиентов, поскольку глубина очереди растет. Затем, когда глубина очереди начинает уменьшаться, дополнительные потребители отмирают. Таким образом, потребители могут быть автоматически масштабированы для изменения нагрузки. Другие брокеры обычно имеют схожие функции.
  • Сделать очередь и основную файловую систему действительно большой. Этот метод пытается поглотить пики в рабочей нагрузке целиком в очереди. Это, в конце концов, то, что планировалось в первую очередь. Проблема в том, что она недостаточно масштабируется, и вы должны выделить диск, который в 99% случаев будет почти пустым.
  • Срок действия старых сообщений. Если у сообщений есть срок действия, вы можете заставить их очистить. Некоторые брокеры JMS будут делать это автоматически, а на других вам может понадобиться просмотреть очередь, чтобы удалить истекшие сообщения. Проблема заключается в том, что не все сообщения теряют свою бизнес-ценность и становятся доступными для истечения срока действия. Большинство сообщений о пожаре и забывании (журналы аудита и т.д.) Относятся к этой категории.
  • Дросселируйте назад производителя. Когда очередь заполняется, ничто не может помещать в нее новые сообщения. В WebSphere MQ производящее приложение затем получает код возврата, указывающий, что очередь заполнена. Если приложение различает фатальные и временные ошибки, оно может остановиться и повторить попытку.

Ключом к успешной реализации любого из них является то, что вашей системе разрешено предоставлять "мягкие" ошибки, на которые приложение ответит. Например, во многих магазинах будет повышаться параметр MAXDEPTH очереди при первом получении условия QFULL. Если глубина очереди превышает размер базовой файловой системы, результатом является то, что вместо "мягкой" ошибки, которая воздействует на одну очередь, заполняется файловая система, и затрагивается весь node. Вам намного лучше настроить систему так, чтобы очередь достигла MAXDEPTH задолго до того, как файловая система заполнится, а затем также применит приложение или другие процессы, чтобы каким-то образом реагировать на полную очередь.

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