Настройка конфигурации FlowLimit - это параметр BusinessWorks, поэтому я предполагаю, что у вас есть механизмы BusinessWorks, которые потребляют сообщения из очереди EMS.
Концепция управления потоком существует, чтобы гарантировать, что количество входящих эвенов для механизма BusinessWorks не приведет к тому, что JVM превысит доступные ресурсы памяти. BusinessWorks реализует управление потоком, временно отключая стартер процесса, пока количество заданий в памяти не станет ниже порогового значения. В случае запусков процессов на основе EMS это приводит к закрытию MessageConsumer, что заставляет EMS прекратить доставку сообщений в процесс. В сценариях с большими объемами сообщений это приведет к отставанию сообщений на сервере EMS. Кроме того, это приведет к повторному приостановке любого сообщения в кэше предварительной выборки на стороне клиента для повторной доставки на стороне сервера EMS. Когда это произойдет, вы заметите, что количество исходящих сообщений больше, чем количество входящих сообщений в статистике EMS.
Лучше всего избегать попадания в контролируемые потоком сценарии. Является ли ваш текущий FlowLimit параметр реалистичным для размера кучи, который вы назначаете JVM и размеры полезных данных сообщений, с которыми работаете? Можете ли вы увеличить размер кучи JVM, а также ваш FlowLimit? Можно ли запускать несколько экземпляров приложения BusinessWorks, отправляющих одну и ту же очередь, чтобы увеличить масштабируемость? Подходы могут помочь вам масштабировать и избегать отставаний в сообщениях.
В нормальном случае Tibco обрабатывает 50-60K сообщений в час. При увеличенном притоке количество обработанных сообщений падает ниже 50K, и я предполагаю, что это из-за остановки потребителя сообщения с помощью процесса ограничения потока и повторного приоритета и повторная доставка сообщений на сервере EMS Client. Правильно ли я понимаю? Любые более эффективные способы избежать этого. Также нам нужен предел потока, иначе количество экземпляров увеличится и постепенно перейдут все ресурсы на сервер. – GKN
Я лично считаю, что ограничение потока и JVM хороши для нормальной полезной нагрузки, но с 5- 10K дополнительных сообщений в час, это становится хитом. Статистика мудрая, я могу показать ухудшение производительности, но нужно технически доказать, чтобы добавить дополнительные ресурсы в процесс. Может предложить мне какую-нибудь идею? – GKN
Как найти пороговое значение для контроля потока, присутствующего в двигателе BW? – GKN