Virtual threads enablement demo patch #28317
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This code provides a quick-and-dirty way to run HTTP requests that would normally be handled by the Liberty default thread pool on Java virtual threads instead. This is NOT how we would implement virtual threads in Liberty for product delivery - it is just a test or demo tool, which allows A-B comparison of between virtual threads and the ExecutorService backing the Liberty thread pool.
To access the patch, you can:
com.ibm.ws.channelfw
project with this PR included- the attached channelfw jar works with Open Liberty builds from 23.0.0.12 thru 24.0.0.4
future changes to the channel framework might break this jar
com.ibm.ws.channelfw_1.0.89.jar-virtual-threads-patch-jdk-21.zip
** the patch jar was built with JDK 21 - it should work with JDK 21 or higher JDKs, but will not work with JDKs prior to 21
With the patch in place, the default handling of HTTP requests is unchanged - they are routed to the Liberty default thread pool for handling. To switch to using virtual threads, a system property must be set to true - this can be done by adding this line to the jvm.options file for the Liberty server:
-DwqmUseVirtualThreads=true
With the "use virtual threads" property set to "true", the first few (default 10) requests are still routed through the Liberty thread pool, after which subsequent requests are handled with a virtual thread. The reason for this approach is that the first request to an application will typically result in a burst of classloading activity for the classes required by the application. That classloading activity involves some blocking I/O operations as class data is retrieved from storage media. The virtual threads infrastructure responds to blocking actions on mounted virtual threads by spinning up extra carrier threads to compensate for the blocked ones. Those extra carrier threads can muddy the view of virtual threads activity when looking at the data later to see how many thread of what type were doing what during a load test. By letting the first few application requests be handled by the Liberty thread pool, we can mostly avoid the phenomenon of "extra carrier threads spun up when load is first applied".