Memory leak because of receive timeout and task executor out of tune conf

Question

I'm going through spring integration reference document and in section 10.1.8 Asynchronous Polling it's written that out of tune conf can cause memory leak.

As per docs below is out of tune conf :

<int:channel id="publishChannel">
    <int:queue />
</int:channel>
<int:service-activator input-channel="publishChannel" ref="myService">
    <int:poller receive-timeout="5000" task-executor="taskExecutor" fixed-rate="50" />
</int:service-activator>
<task:executor id="taskExecutor" pool-size="20" />

I'm having trouble in understanding this section as it's written 4 threads will be executed every second as each thread will wait for 250 ms and task will be added at rate of 20 per second.

Shouldn't task executor assign only 1 thread to wait for incoming message and should start max threads in case there's sufficient task in queue? Also why only 4 thread will execute per second what if task takes more than 250 ms?

Apologies if it's too simple and I'm missing something trivial.

Answer 1

The <task:executor id="taskExecutor" pool-size="20" /> is with an unbounded task queue. This is that default one.

The task-executor="taskExecutor" fixed-rate="50" means don't block scheduler's thread and scheduler starts a new poll every 50 milliseconds! And it happens indeed independently of the publishChannel content. I mean the new task is always placed into taskExecutor queue.

If the process downstream is really long enough, all 20 threads of the executor are going to be busy and that internal queue for tasks is going to grow. That's where memory leak comes to the top.

1 second/ 50 millis = 20 tasks per second.

If there are no messages in the publishChannel, I would say all the threads in the task executor are going to be busy waiting for 5 seconds timeout. So, what is the rate for tasks? 20 active tasks / 5000 millis to wait for their finish = 4 per second.

The story is not about 4 threads, it is indeed how fast we are able to drain task queue in the worth case.