Enable support for project loom for Jetty's thread pool

[zUniQueX]

This PR provides a new configuration option to enable virtual threads for Jetty's thread pool.

If the current runtime doesn't support virtual threads, platform threads are used instead.

[zUniQueX]

@dropwizard/committers This implementation should be enough to enable virtual threads. For basic testing we could ship with this implementation and add support for virtual thread executors in the dropwizard-lifecycle module later IMHO.

Blocked by dropwizard/metrics#3531

[mattnelson]

Do any of the other thread based properties need to be handled/documented differently when virtual is enabled?

• maxThreads
• minThreads
• adminMaxThreads
• adminMinThreads
• idleThreadTimeout
• acceptorThreads
• selectorThreads

[cty123]

Thanks for working on supporting project loom, is there a plan to backport this change to release 3.x?

[zUniQueX]

Hi @cty123. As mentioned in the release notes, Dropwizard 3.x and 4.x should be kept in sync. Since the release/4.0.x branch is the default one, ongoing development is targeted there. After the merge the changes from 4.x will be backported to 3.x.

[zUniQueX]

@dropwizard/committers Anyone available for this PR?

[zUniQueX]

Do any of the other thread based properties need to be handled/documented differently when virtual is enabled?

* maxThreads

* minThreads

* adminMaxThreads

* adminMinThreads

* idleThreadTimeout

* acceptorThreads

* selectorThreads

minThreads, maxThreads and idleTimeout are set with the constructor of the main InstrumentedQueuedThreadPool and will use virtual threads now from Jetty's default thread pool.

acceptorThreads and selectorThreads obtain threads from the same thread pool and therefore will also use virtual threads.

For the admin connector the InstrumentedQueuedThreadPool doesn't set a ThreadFactory yet and therefore won't use virtual threads. I'm not sure, if applications will benefit much from virtual threads on the admin connector. But we can discuss introducing a separate property for this use case.

[pstackle]

In general, LGTM.

I do wonder if we shouldn't fail more obviously in the case that the user configures enableVirtualThreads: true and it can't work (either isn't supported or the reflection code fails). It seems like Dropwizard's typical approach is to fail rather than quietly ignore a config setting (beyond a warn log statement).

[zUniQueX]

@pstackle Thanks for the fast review!

I wanted to introduce the logs only for an easier migration path. But I agree with you, that users should be notified more than that, if the application cannot do what's requested. I've revised the PR and the code now throws exceptions.

I additionally added support for virtual threads on the admin connectors. Then the behavior of the connectors is more similar. But for the separate thread pool there is a separate configuration option to enable it.

Do you think we should provide any other documentation than the configuration options? I'm not sure it's a topic this big since most users will most likely not directly migrate to Java 21 and make use of virtual threads. The interested users probably have already seen the issue and this pr 😉 If you think so, I'll leave a short note in the core docs.

[pstackle]

Found one nitpick in an exception message, but otherwise, I'm happy with this.

[pstackle]

I think this feature is likely one that is worth calling out specifically in the release notes, because this is one of the main features in Java 21. I can't really think of a place in the other docs that it would make sense to reference this. Especially because we'd have to caveat it with that you must be running Java 21 or greater to even enable it.

[zUniQueX]

Sounds good 👍