6 Replies Latest reply: Sep 1, 2011 6:05 PM by 884440 RSS

    Best Practice: ExecutorService#execute v.s. BlockingQueue

    Johnny_hunter
      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
        • 1. Re: Best Practice: ExecutorService#execute v.s. BlockingQueued
          802316
          An ExecutorService has a BlockingQueue and a thread pool. When you manage an ExecutorService you manage both (the thread pool is usually harder)
          With an ExecutorService you can submit any type of Runnable or a Callable and obtain its result.

          I suggest you limit the number of threads and an unbounded cache thread pool can overload the system, a state from which your system may not recover (as it takes longer and longer to service each request/task)

          If you are accessing a database its is likely you want a small thread pool to compensate for the latency accessing a database introduces. I would start with a pool of four and increase/decrease it when you see the system running. (Ideally make it configurable)
          • 2. Re: Best Practice: ExecutorService#execute v.s. BlockingQueued
            Johnny_hunter
            thanks peter, can you eleborate a little further: what do you mean by
            When you manage an ExecutorService you manage both
            ? When will be queue is used? Myabe it's used when we use submit instead of execute?
            What's the underlying implementation of the thread pool if the implementation is not a queue?

            Using fixed thread pool is the right choice. However, I believe the best practise is that we can test the app using cached thread pool and switch to fixed ones when it's deployed.

            Thanks, John
            • 3. Re: Best Practice: ExecutorService#execute v.s. BlockingQueued
              884440
              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 :)
              • 4. Re: Best Practice: ExecutorService#execute v.s. BlockingQueued
                884440
                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 :)
                • 5. Re: Best Practice: ExecutorService#execute v.s. BlockingQueued
                  884440
                  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 :)
                  • 6. Re: Best Practice: ExecutorService#execute v.s. BlockingQueued
                    884440
                    WTF just happened? My reply got posted thrice!