Which channel and which activator?

[PeterTeunissen]

I am working on an application that uses Spring Framework/Spring-Integration. It exposes two web services and runs under websphere. During the processing of the webservice request the application generates performance numbers which I want to persist. I don't want to make the thread executing the webservice request wait for that. So I want to use a channel where the main thread just posts the performance data into the channel and continue (no waiting for it to be processed). On the other end of the channel I want a process that picks off one entry, persists and continue to the next entry in the channel. I want only one thread to be listening to do that work and keep other threads free to do the webservices work. I currently have this working with a pollable channel and a service activator that uses a fixed poller. What is the best setup to do this?

	
   	<si:channel id="ccc.performanceChannel"><si:queue capacity="10000"/></si:channel>

   	<si:service-activator id="ccc.performanceActivator" ref="ccc.performanceWorkerAT" 
		method="onMessage" input-channel="ccc.performanceChannel">
		<si:poller fixed-delay="1000"  task-executor="ccc.WorkManager">
			<si:transactional transaction-manager="transactionManager"/>
		</si:poller>
	</si:service-activator>

[Mark Fisher]

Another option is to provide a task-executor to a channel's dispatcher:

<channel id="ccc.performanceChannel">
    <dispatcher task-executor="someSingleThreadExecutor"/>
</channel>

It's a subtle difference: queueing of dispatch tasks within the Executor instead of Messages queueing in a channel's backing queue. In either case, you might need to consider a capacity on the queue. With a queue-backed channel, that means the sender could trigger an Exception when the capacity is reached. With the dispatcher approach, that leads to a need to configure a "rejection-policy" on the Executor. That said, one advantage to using a queue-backed channel is that you can also provide a message-store reference. Depending on the implementation you reference, you can add persistence of those Messages that are buffered. That might even be a transactional implementation so that the original thread can participate in the transactional hand-off while still having the benefit of asynchronous sending of the performance data. Of course, with a MessageStore behind the queue, you may also eliminate the need to worry about capacity limits. If you don't need persistence and you even consider dropping messages when capacity is reached to be OK, then the dispatcher approach is simpler.

I hope that's a clear explanation. Let me know if not...

-Mark