Llowering core pool size on task executor does nothing?

[newmann]

Hey,

I am using spring integration to perform parallel processing on channel outputs. I have a requirement that the amount of parallelism that goes on needs to be controllable - so I need to be able to increase it or to lower it dynamically. Here is my current set up:

<service-activator input-channel="computerInputChannel" ref="computer" method="compute">
  <poller task-executor="computerRequestExecutor" fixed-rate="1000"></poller>
</service-activator>

<task:executor id="computerRequestExecutor" pool-size="1" queue-capacity="100" />
<channel id="computerInputChannel"><queue/></channel>

and in code, when I want to change the amount of parallelism, I run the setCorePoolSize method.

My problem is that when I increase the core pool size, I get increased parallelism, but when I then decrease the core pool size, the increased parallelism doesn't go away. For example, if the core pool size is set initially to 1, I see the tasks run one at a time. And if it is then set to 5 I see them run 5 at a time. But if I reset it to 1, they'll continue to run 5 at a time.

How can I throttle the parallelism?

I am very new to spring integration and may be approaching this from the wrong angle. Any help or alternate suggestions for how to achieve what I want would be great.

http://forum.springsource.org/showth...s-taskexecutor is pretty much my exact question if what I wrote was unclear - unfortunately it was never answered.

Thanks!

[Gary Russell]

There are two things that affect this; first is, if there is already work enqueued for the task executor, the "extra" threads won't terminate while there is work still to do.

Second, the default 'keep-alive' is 60 seconds - meaning a thread has to be idle for that long before it will stop.

These are both functions of the underlying JVM ThreadPoolExecutor (but Spring sets the default keep-alive to 60 seconds - you can adjust it with the 'keep-alive' attribute).

[newmann]

Thanks! It was this that I needed, but also one more thing - the max-messages-per-poll had to be set to 1 for the behavior I expected. I saw this after analyzing the Poller class in AbstractPollingEndpoint - the 'tasks' given to the taskExecutor won't terminate if there are still messages on the channel queue otherwise, and my channel is basically always busy.