Best Practice: ExecutorService#execute v.s. BlockingQueue

Question

Hello all:
I have a choice to make here.
I am developing a server app. It takes requests from a message broker and use these requests as conditions to fetch data from backend d-base and send back to the broker's topic again.
The idea is simple and straightforward. I construct runnable tasks to do the above job, and I created a cached thread pool (Executors#newCachedThreadPool) , and pass the task to ExecutorService#execute , piece of cake.
the code works fine in testing phase. However I have been obsessed with the idea of using a blocking queue.
In my mind, the implementation using queue is as follows:
- construct runnable tasks as above;
- put the task into the queue;
- create a thread (or a runnable passed to a ExecutorService#execute ), which runs tirelessly (endless loop) to pick the task from the queue and call task#run.
I think the choice is depending on the volumes of the client requests. If that's not too many, a cached thread pool assigning a thread for each request might be appropriate; otherwise, a fixed size threadpool or blocking queue might be preferable?
BTW, what's the difference b/w a fixed thread pool and a blocking queue solution? It seems to me that they have the same effect since the size of both is fixed.
Thanks, John

Answer 1

An ExecutorService has a executor and a threadpool and you submit your task in that pool. Those pool takes a work queue, be it a blockingQueue, or a non blockingQueue or a Synchronous queue, and they are managed by the ExecutorService class. You also specify what kind of pool you are interested in. And then, ES manages both.
You ought not to invoke execute() method on a ES: it returns void! You want some result bearing computation, else you could have used Executor and just invoke execute! If you think about PC design pattern, you need a queue to where the producer places the tasks and consumer consumes from it. That's the idea of queue.
In your case, I'd have avoid using cacheThreadPool as it creates unlimited number of threads. Rather, I'd have used a bounded blocking queue just to be on safer side. Let me know in case you want to discuss more :)