CODEWITHSUNDEEP
javaguavaexecutorservice
Ray
Ray

Reputation: 4869

Resizeable ListeningExecutorService

I've gotten into the habit of wrapping ExecutorServices in a listeningDecorator to make a ListeningExecutorService. I understand this is the Guava team's recommendation, and it seems to always be worthwhile.

I am running into an issue here, however. My executors are invariable based on a standard ThreadPoolExecutor, and I would like to give control of that thread pool size to my application (and, particularly, to expose it to administrators supporting the application). With an undecorated ThreadPoolExecutor, the methods needed to do this are exposed, but the wrapper is hiding the delegate from me.

So, what would I need to do to get back to the api exposed by the ThreadPoolExecutor without giving up the listeningDecorator?

A couple of ideas I had were:

  1. Make a new ListeningDecorator that exposes the delegate
  2. Keep a reference to the delegate as well as to the decorated Executor
  3. Only keep a reference to the ThreadPoolExecutor, and wrap it only when the ExecutorService as it is requested
  4. Reflect my way in to the delegate and manipulate the thread pool size from there

Upvotes: 1

Views: 285

Answers (1)

Louis Wasserman
Louis Wasserman

Reputation: 198133

Guava team member here.

I would write a new ListeningThreadPoolExecutor class that's basically a ListeningDecorator variant wrapping a ThreadPoolExecutor, but instead of exposing the delegate itself, I'd expose setCorePoolSize(int size) methods from the ListeningThreadPoolExecutor that forwarded to the delegate ThreadPoolExecutor.

That approach exposes even fewer internal details than option 1, but failing that, I'd fall back to option 1 as you've described it.

Upvotes: 2

Related Questions