Hi Doug, What are your thoughts on promoting monitoring methods from TPE and or FJP to AbstractExecutorService? The default implementations could just return -1. An example precedent is OperatingSystemMXBean::getSystemLoadAverage. The Executors.DelegatedExecutorService could then be modified to extend AbstractExecutorService and forward the new methods and the existing AES::taskFor calls when the wrapped Executor is also an AbstractExecutorService. The return types of the Executors.newXXX would remain the same.
I suppose the tradeoff is that adding any new default method to ExecutorService and or new methods to AbstractExecutorService could break 3rd party code. Jason ________________________________________ From: core-libs-dev <core-libs-dev-r...@openjdk.java.net> on behalf of Doug Lea <d...@cs.oswego.edu> Sent: Thursday, January 7, 2021 7:09 AM To: core-libs-dev@openjdk.java.net Subject: Re: Monitoring wrapped ThreadPoolExecutor returned from Executors 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?
