2
votes

I have a API, which is doing four tasks. If we do sequential this API will take more time.
To increase the performance I have used Executor service framework and submitted four task using executor service.

As i know creating thread is expensive operation, and in executor service thread will be created at the time of submitting the tasks. And threads will be destroyed when we call shutdown method of executor service.

This is the process of each request in this scenario :

  1. API call
  2. create executor service
  3. submit the four future task
  4. Create the response from all return threads.
  5. call shutdown executor service method.
  6. return the response

So my question is creating executor service and threads in each request is correct or not? Or please let me know alternative solution of this.

3

3 Answers

2
votes

No, it’s not wise to terminate and re-instantiate ExecutorService frequently. That’s the whole point of it. Create a fixed thread pool as you already know the number of tasks you want to carry out in parallel. Also decouple your request handler from creation of ExecutorService. Note, you’re calling shutdown(), meaning finish the current tasks and do not accept any new tasks, it’s not reusable, it forces you to reinstate the pool per request, so try not to terminate the thread pool.

2
votes

It's perfectly fine to use a thread pool to parallelize processing of incoming requests. But it's not fine to create a new thread pool on each API call.

In order to do this right, you should create a separate ExecutorService instance and simply reuse it, and shutdown it only when you shutdown the application.

Also, remember about sizing it properly because if it gets saturated, it will degrade your latency instead of improving it.

-1
votes

Create a singleton of your ExecutorService and use that same instance for all requests. DO NOT create it over and over again. You should also limit the maximum number of threads owned by the ExecutorService to prevent your REST API from blowing up your server.