aspose file tools*
The moose likes Threads and Synchronization and the fly likes Threads in web application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Threads in web application" Watch "Threads in web application" New topic
Author

Threads in web application

samir ware
Ranch Hand

Joined: Jul 27, 2005
Posts: 192
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

Joined: Jun 14, 2013
Posts: 103
    
  11
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Threads in web application