Hi, Samir.
Two important questions.
1. What is a ThreadPoolTaskExecutor? I can't find this class in JDK 7. Is it a custom class or you just misspelled one of the standard executor classes?
2. Didn't you mix up alive and running thread states?
These questions are important. In a correct executors
you should see an idle threads in a "WAITING/TIMED_WAITING" state (thread is alive, but is not "running") most of the time. There may be spurious wakeups (so, sometimes you may see a running state), but is should not be all the time. If threads are really in running state, then you should check your task executor implementation (and task queue implementation in particular).
Regarding other questions.
ThreadPoolTaskExecutor will never get opened for next request and I get the exception.
Yes, thread pool does not restart iteslf automatically. If you shutdowned task executor, you should create another executor next time. This is a designed behavior. For example, this may prevent pool from autostart when tasks are submitted from different threads. Other solutions will involve manual synchronization to check executor's state, which may be bothersome.
Is keeping the threads in running state even when their processing is done is desired behaviour or I need to make them sleep or in ready to run state when their processing is done ?
Double check an exact thread state. Probably you should check tread state with some intervals (not immediately after a task execution). If there are no jobs, threads should be in waiting state. You can't properly wait in a worker threads because correct waiting involves interactions with an executor internals (orders queue for example). Maybe there are other users of this pool, so other tasks are executed?
Anyway, "alive" idle threads are OK. Executor just want to reuse some of these threads when new tasks are available. You should not bother about several live threads unless you have a hundreds of executors at the same time.
If I have to return the threads sleep when processing is done, how can I do that using ThreadPoolTaskExecutor ?
You should not return thread to a sleeping state. It's not practical. You should want waiting thread. And it may take some time to enter into a waiting state for a thread. It is usually milliseconds (some small portion to check queue and start waiting), but if you check thread states immediately after a completion of a last job, such timeouts can make difference.
Any white paper, link will greatly be appreciated.
Read
ThreadPoolExecutor's javadoc. It contains a pretty good description of a thread management policy. You should read "Core and maximum pool sizes", "On-demand construction" and "Keep-alive times" paragraphs. Thread pool executor can grow and shrink amount of alive threads based on actual usage. And you may fine-tune these policies. For example, you may set "core size" to zero and set some keep-alive timeout. This will allow executor to shutdown all "unused" threads.