Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Virtual threads enablement demo patch #28317

Closed

Conversation

gjdeval
Copy link
Member

@gjdeval gjdeval commented May 1, 2024

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:

  • build Open Liberty with this PR included
  • build just the com.ibm.ws.channelfw project with this PR included
  • use the channelfw jar attached to this PR in an Open Liberty installation
    - 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".

@LibbyBot
Copy link

LibbyBot commented May 1, 2024

Code analysis and actions

DO NOT DELETE THIS COMMENT.
  • 2 product code files were changed.
  • Please describe in a separate comment how you tested your changes.

@gjdeval gjdeval requested a review from jhanders34 May 1, 2024 14:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants