Monitoring wrapped ThreadPoolExecutor returned from Executors
pavel.rappo at oracle.com
Wed Jan 6 12:20:56 UTC 2021
Questions related to the contents of java.util.concurrent.** should generally be asked on the "Concurrency-interest" mailing list: http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> On 6 Jan 2021, at 03:11, Tommy Ludwig <tludwig at vmware.com> 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 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?
> From the JavaDocs, the intention of the wrapping is to prevent changing the ThreadPool configuration. Our use case does not call for changing the thread pool configuration - we want to observe the ExecutorService (e.g. thread pool state) via getter methods for monitoring purposes.
>  https://github.com/micrometer-metrics/micrometer/blob/25f120833f8b73e4bd7cf604831dfddf0112fe9c/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/jvm/ExecutorServiceMetrics.java#L272-L301
More information about the core-libs-dev