Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Threads in web application

 
samir ware
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ranchers
I am working on a web application in which there are few DB inserts happening. All these DB inserts I am doing thorough JAP by using multiple threads.
I am little confused about the fact that I can see all my threads in running state even when their processing is done.
I am using ThreadPoolExecutor for creating threads. Although if I close the threadpoolExecutor as shown below, when the thread is done with the processing, ThreadPoolTaskExecutor will never get opened for next request and I get the exception.




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 ?
If I have to return the threads sleep when processing is done, how can I do that using ThreadPoolTaskExecutor ?
Any white paper, link will greatly be appreciated.

Thanks in advance
Samir
 
Maxim Karvonen
Ranch Hand
Posts: 121
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic