Fix ResourceTracker in benchmark to work fine with VIRTUAL_THREAD #234
Conversation
| String name = threadInfo.getThreadName(); | ||
| log.debug("Tracking target check for thread name: {}", name); | ||
| if (name.startsWith("DecatonSubscriptionThread-") || name.startsWith("PartitionProcessorThread-") || | ||
| subPartitionRuntime == SubPartitionRuntime.VIRTUAL_THREAD && name.startsWith("ForkJoinPool-")) { |
There was a problem hiding this comment.
So if we have another fork join pool (though currently we don't) in benchmark runtime or somewhere, it may be miscounted as the resource usage.
I think it's acceptable compromise for now though, can we identify virtual thread runtime's pool more precisely somehow? (e.g. by customizing carrier thread's thread factory?)
There was a problem hiding this comment.
None without any sorts of dirty work :(
There was a problem hiding this comment.
I see, thanks. The only way I can imagine (substituting VirtualThread's scheduler by accessing package-private class) is also dirty so let's do in current way for now
| ScheduledExecutorService executor = Executors.newScheduledThreadPool( | ||
| 1, Thread.ofPlatform().daemon().factory()); | ||
| executor.scheduleAtFixedRate(() -> { | ||
| for (int i = 0; i < Runtime.getRuntime().availableProcessors(); i++) { |
There was a problem hiding this comment.
Does submitting tasks up to availableProcessors count ensure keeping all ForkJoinPool worker thread to keep alive?
There was a problem hiding this comment.
Yeah it worked based on my observation.
No description provided.