spring integration processing messages in a concurrent manner

Question

I am trying to setup my application using spring integration, being a newbie, need advice on below use case -

There is queue where messages from another application are getting pushed. My application consume messages from the queue, does some data massaging and then push it to another outbound queue. Goal is, to process messages in a concurrent way.

As per my understanding we can have 2 approaches-

1- Using #Poller

<int:service-activator ref="messageProcessor" method="process" input-channel="incomingChannel">
    <int:poller fixed-rate="100" task-executor="executor" />
<int:service-activator/>
<task:executor id="executor" pool-size="10"/>

2- Using #Dispatcher

<int:channel id="incomingChannel">
    <int:dispatcher task-executor="executor"/>
</int:channel>
<int:service-activator ref="messageProcessor" method="process" input-channel="incomingChannel" />

<task:executor id="executor" pool-size="10"/>

Looking at the poller based configuration it seems that, there will be multiple threads available in the pool, fetching messages and processing it concurrently. Concern here is-

i) Poller will keep running in the background unnecessarily (resource hit).

ii) Even if messages are there on the channel, will be wasting milliseconds based on the fixed-rate (as poller will fetch messages after every 100 seconds).

Dispatcher based configuration seems to be message driven and may be perfect for my use case. Correct me if I am wrong, In this case threads are only responsible for dispatching the message to a subscriber.

If that is the case-

Do I need to have multiple service activators associated with the channel ?

Is there any way to attach multiple instances of same service activator config dynamically?

Suggest me what is best approach to deal with this. Thanks.

Gary Russell Gary Russell · Accepted Answer · 2015-10-27T12:27:43

(i) The polling is extremely lightweight; even with a fixed-rate of 0, the thread will block in the channel for 1 second (by default - receive-timeout); I doubt you would even measure the cpu used by an idle poller.

(ii) See (i) - reducing the poll interval will alleviate any latency.

In any case, if you are talking about JMS, you probably don't want to use either approach - if you want the outbound send to participate in the same transaction as the inbound message (i.e. only commit the removal if the send succeeds), you must not hand off to another thread - if you do so, the message removal will be committed immediately at that time.

Instead, use a message-driven channel adapter and use its concurrency settings to increase the number of threads; then use direct channels throughout.

spring integration processing messages in a concurrent manner

1 Answers