Jetty thread pool no longer has dw-* naming?

[mattnelson]

Recently uplifted to 3.x and noticed that the thread pool serving the requests is no longer named dw-*.

dropwizard/dropwizard-core/src/main/java/io/dropwizard/core/server/AbstractServerFactory.java

Line 671 in 71d5de5

threadPool.setName("dw");

Before it was something like dw-* now they are pool-6-thread-*.

[zUniQueX]

Hi @mattnelson. That's because we're using the default ThreadFactory builders of the class library instead of the ThreadFactory from Jetty's QueuedThreadPool in 3.x to support virtual threads.

Should we explicitly set the names of those threads to prefix them with dw?

[mattnelson]

For the non-virtual case, I think it should defer to Jetty by passing a null ThreadFactory, which then uses itself[1] for the ThreadFactory and will honor the name[2].
For the virtual case, call name on the builder[3]?

[1] https://github.com/jetty/jetty.project/blob/jetty-10.0.20/jetty-util/src/main/java/org/eclipse/jetty/util/thread/QueuedThreadPool.java#L180
[2] https://github.com/jetty/jetty.project/blob/jetty-10.0.20/jetty-util/src/main/java/org/eclipse/jetty/util/thread/QueuedThreadPool.java#L907
[3] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.Builder.html#name(java.lang.String,long)

[zUniQueX]

@mattnelson I don't like using different patterns for the two thread types. If Jetty would update the naming pattern, the threads names would differ, if someone enables virtual threads. Then I'd vote for simply using the current Jetty naming scheme and implementing the thread naming ourselves. Then the thread names would be consistent between virtual and non-virtual ones.

[shahr]

I agree with @zUniQueX. I came to this thread as I had noticed this too. In my opinion, the custom thread naming is definitely super useful, especially when using something like Visual VM for debugging. Plenty of other libraries don't really do thread naming properly and filtering for (or out) dw* is easier "pool-something" because lots of other things just use the default naming. It also helps with identification within logs.

[mattnelson]

I don't like using different patterns for the two thread types

I was not advocating for that. The thread name should be consistent regardless of virtual or not. My suggestion to pass null to QueuedThreadPool is because QTP is already an instance of ThreadFactory, so in the non-virtual case the extra ThreadFactory object is not needed.

I'm wondering if the current implementation should be refactored due to adding first class virtual thread support in 10.0.12 > jetty/jetty.project#8360

[zUniQueX]

I was not advocating for that. The thread name should be consistent regardless of virtual or not. My suggestion to pass null to QueuedThreadPool is because QTP is already an instance of ThreadFactory, so in the non-virtual case the extra ThreadFactory object is not needed.

IMHO, this was too much overhead for a ThreadFactory. Therefore I went with the JDK objects. Relying on Jetty objects sounds good, if they support both the virtual and non-virtual case. If they only support one of them, we should ship our own implementation to enforce consistence on our side.

I'm wondering if the current implementation should be refactored due to adding first class virtual thread support in 10.0.12 > jetty/jetty.project#8360

Sounds reasonable. But getThreadFactory(boolean) would be obsolete then and we would modify the public API. I think we should do this only in the release/5.0.x branch.