Solace JCSMP API показывает «Перегрузка абонентского потока» - PullRequest
0 голосов
/ 13 октября 2018

При использовании Java-библиотеки Solace JCSMP, подписавшейся на темы с высокой нагрузкой с помощью Direct Messaging, я получил следующее.Могу ли я знать, как это повлияет?Приведет ли это к потере сообщений и что за средство?

2018-10-08 10:18:43 INFO  FlowHandleImpl:67 - Subscriber flow congested, disabling connection read.
2018-10-08 10:18:43 INFO  FlowHandleImpl:42 - Subscriber flow uncongested, re-enabling connection read.

1 Ответ

0 голосов
/ 13 октября 2018

По мнению Solace Support, это вызвано переполнением внутренней очереди потока сообщений в API.Ниже приводится краткое изложение того, что я понимаю из службы поддержки Solace.

API Java поддерживает внутреннюю очередь сообщений для доставки в сеанс потребителя.Если эта очередь достигает предела загруженности потребителя (по умолчанию 5000 элементов), API прекращает чтение из сокета, и рабочие очереди выходного буфера подвергаются обратному давлению на маршрутизаторе Solace.Когда это происходит, создается журнал «Поток абонента, отключение чтения подключения».Это может привести к сбросу сообщений.Как только приложение поймает, что API возобновляет чтение из сокета и генерирует журнал, такой как «Поток подписчика не перегружен, повторное включение чтения соединения».

Мы можем настроить это, вызвав setConsumerDefaultFlowCongestionLimit () of com.solacesystems.jcsmp.JCSMPGlobalProperties

Следующие команды CLI могут использоваться для проверки отклонений сообщений при возникновении этой проблемы:

show client <name> stats detail
show client <name> connections wide
show client <name> stats queues

Если сообщения публикуются с помощью Deliver-To-Один (DTO), установленный в значение true, затем увеличение числа подписчиков сообщений поможет сбалансировать нагрузку, и проблема сбросов сообщений может быть облегчена.

Интересно также узнать, как Solace API обрабатывает входящие сообщения с помощью Потоки при получении сообщений , чтобы понять эту проблему.

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

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

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

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