Single or multiple thread pools for Java server?

Question

I am writing a fairly complex Java server application which has a significant background processing portion in addition to the usual request-response processing. Some of the background processing is done in a cron-like fashion using Quartz framework. Other tasks are more of on demand - if a new client connects it creates additional job for updating it once in a while. The cron tasks can also be varied - some do monitoring of external applications, some calculate statistics and so on.

I am using a number of thread pools to run all those jobs with the idea that similar jobs will share a thread pool but different jobs will not share one. For example monitor jobs will never run on statistics pool, and statistics jobs will never run on monitor pool.

On the other hand I know some people would prefer just to have a single thread pool and run everything on it without any separation.

I wonder what is considered the best practice in such a scenario.

What are the pros an cons of separating thread pools?

Does it even matter?

Answer 1

It's not really a direct answer, but another proposal :-(

Your Quartz jobs can be paused, canceled and so on, let's call it "managed". I guess you will create some UI to manage them.

Do you realize that you your other jobs ("on demand") will not benefit from the same functionalities, unless you implement it of course? Did you consider making everything a quartz job (even if it starts immediatly), to get a uniform code?

Answer 2

The answer depends on whether you need to segregate application resources between different types of activity or not.

For example, I am currently writing a server application consisting of a few high-throughput writers and potentially many readers. Readers will access the app sporadically but could potentially request a lot of data (i.e. long running requests). I need to ensure that writers are never starved so am going to use two thread pools in my design for reading / writing. If the reader thread pool is temporarily exhausted the writers will be unaffected; only read requests will be delayed.

An alternative would have been to use a PriorityQueue in conjunction with a ThreadPoolExecutor and assign a higher priority to write requests.

So in conclusion - My advice would be: Start off with one thread pool and only make your design more complex if there's a concrete reason for doing so.