Monitoring wrapped ThreadPoolExecutor returned from Executors

Doug Lea dl at cs.oswego.edu
Thu Jan 7 13:09:27 UTC 2021


On 1/5/21 10:11 PM, Tommy Ludwig wrote:
> In the Micrometer project, we provide metrics instrumentation of `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of completed tasks, active tasks, thread pool sizes, task queue size and remaining capacity via methods from `ThreadPoolExecutor`. We are currently using a brittle reflection hack[1] to do this for the wrapped `ThreadPoolExecutor` returned from `Executors` methods `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the introduction of JEP-396 in JDK 16, our reflection hack throws an InaccessibleObjectException by default.
>
> I am not seeing a proper way to get at the methods we use for the metrics (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a way that I am missing?

There's no guarantee that newSingleThreadExecutor returns a restricted 
view of a ThreadPoolExecutor, so there can't be a guaranteed way of 
accessing it,

But I'm sympathetic to the idea that under the current implementation 
(which is unlikely to change anytime soon), the stats are available, and 
should be available to monitoring tools. But none of the ways to do this 
are very attractive: Creating a MonitorableExecutorService interface and 
returning that? Making the internal view class public with a protected 
getExecutor method?




More information about the core-libs-dev mailing list