Virtual threads enablement demo patch

[gjdeval]

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]

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.