Spring Integration

Наше приложение было разработано с использованием Spring Integration Framework. Полный поток действий с сообщениями начинается с прослушивания очереди, для которой использовались адаптеры, управляемые сообщениями JMS, после чего были определены конечные точки на основе канала, т. е. очереди, и каждая конечная точка обрабатывается активаторами службы.

В настоящее время мы находимся в фазе производительности, мы порождаем запрос на 200 сообщений.Первоначально мы заметили, что сообщения не выполнялись параллельно, после некоторого чтения выяснилось, что добавление свойств concurrent-consumer и max-concurrent-consumer к адаптеру прослушивателя, управляемому сообщениями JMS, поможет включить многопоточный режим. Действительно, это помогло, но все же где-то между процессом я все еще вижу эффект Single Thread. Это связано с тем, как была определена конечная точка? В чем преимущество добавления емкости очереди к каждой конечной точке? Как вы думаете, добавление емкости очереди к каждому определению конечной точки канала снова поможет работать в многопоточном режиме.

Моментальный снимок проекта по запросу:

action flow

6
задан djeikyb 18 November 2016 в 00:05
поделиться