You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optimization/Features/Suggestions around managed executors
The current default thread factory creates a new DefaultThreadFactory instance whenever a new thread is constructed.
For threads we have a global counter. Would prefer a counter per executor service (Use a global pool and local thread number similar to DefaultThreadFactory). Can move threadFactory logic to its own class. Would've extended threadFactory but its a private static class.
nameFormat seems very unintuitive. It's not clear to users that they have to specify one. Also its usage across classes vary. (ScheduledExecutorServiceBuilder doesn't have that requirement).
For points 2, 3 and 4, I've created a draft PR and mentioned changes below. Don't think anything here can be considered as breaking changes. Can update release notes/docs/tests if you think this is a reasonable approach - #3286
User passes a prefix and the threadFactory will add pool/thread number.
Whatever the user passes is what is used in the metric name. The methods getNameWithoutFormat in this Executor metrics shouldn't contain fmt string. #3142 will return a string appended to itself, so it may have to be reverted. @pkwarren - Any feedback/concerns?
Includes managed and instrumented executor service factory methods. ThreadPoolExecutor Javadocs urges users to use the Executors factory methods that preconfigure settings for the most common usage scenarios. Also the InstrumentedExecutorService has additional metrics like idle/duration timers which InstrumentedThreadFactory (used in ExecutorServiceBuilder) doesn't have
The text was updated successfully, but these errors were encountered:
Optimization/Features/Suggestions around managed executors
PR for point 1 - #3285
For points 2, 3 and 4, I've created a draft PR and mentioned changes below. Don't think anything here can be considered as breaking changes. Can update release notes/docs/tests if you think this is a reasonable approach - #3286
The text was updated successfully, but these errors were encountered: