Performance and scalability: Why use thread pools?
I understand the benifit of thread pools over a design where a new thread is started for every request that needs to be processed. However, what is the difference between using a thread pool that can execute generic tasks, and having some threads dedicated to each of the tasks? Assuming that you don't have hundreds of different types of tasks you have to execute, would it not be better to use a thread per task type?
Increasing the number of threads could be productive if the application is not highly CPU bound. If the application is threads are busy doing more IO or waiting for resources, it could be of good help. Nevertheless, increasing the number of threads can be productive in system having more processors.
Example of configuring different pools for differ tasks depends of the implementation. The following scenario could be a good candidate for it:
1. The server processes very few HTTP requests
2. The server processes high volume of messages published via. JMS.
3. EJB activities are performed based on HTTP and JMS activities.
Here, a seperate (or large) thread pool for JMS listeners (or MDBs), which could be shared by the EJBs, and seperate thread pool for HTTP based requests can be appropriate.
I know that Weblogic's thread pool usage can configured. But, still some application servers are not letting the to users to configure their thread pool usage.
Rather than growing your own thread pooling scheme, I'd take a look at the open source API ThreadWorks