[ https://issues.apache.org/jira/browse/CXF-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854048#comment-17854048 ]
Andriy Redko edited comment on CXF-9028 at 6/11/24 1:17 PM: ------------------------------------------------------------ [~getaceres] it is known issue and is being worked on by OpenJDK / Loom team(s), see please announcements below, I believe there is no work / fixes on the table for the time being on Apache CXF side to eliminate synchronization (it is massive effort). ========================== # ## Heads-up - Loom: New EA builds with improved Java monitors implementation to work better with virtual threads Project Loom published new early-access builds [6]. These builds have an improved object monitor implementation that should prevent virtual threads from pinning their carrier thread in the following situations: - when blocking on entering a synchronized method/statement because the object's associated monitor is held by another thread, - when parking (e.g. when doing socket I/O) while in a synchronized method, - when calling `Object.wait` while in a synchronized method. The changes for `Object.wait`/timed-`wait` is the main change since the previous Loom EA build. The Loom team is looking for help to test the changes, i.e., trying out these builds with code that is known to use virtual threads and with libraries that are "very synchronized". The primary goal is to gauge both reliability and performance. Right now, the focus is on being functional and reliable. Please note that the performance for some cases isn't yet fully on par with blocking on j.u.concurrent locks and condition objects. As before, JFR events can be used to identify remaining cases of pinning, parking or blocking in a class initializer for example. The system property `jdk.tracePinnedThreads`, which used to print stack traces when threads are pinned, no longer outputs anything. Please send feedback via email to the Loom mailing list [7] (subscription required). [6] [https://jdk.java.net/loom/] [7] [http://mail.openjdk.org/mailman/listinfo/loom-dev] was (Author: reta): [~getaceres] it is known issue and is being worked on by OpenJDK / Loom team(s), see please announcements below, I believe there is no work / fixes on the table for the time being to eliminate synchronization (it is massive effort). ========================== ## Heads-up - Loom: New EA builds with improved Java monitors implementation to work better with virtual threads Project Loom published new early-access builds [6]. These builds have an improved object monitor implementation that should prevent virtual threads from pinning their carrier thread in the following situations: - when blocking on entering a synchronized method/statement because the object's associated monitor is held by another thread, - when parking (e.g. when doing socket I/O) while in a synchronized method, - when calling `Object.wait` while in a synchronized method. The changes for `Object.wait`/timed-`wait` is the main change since the previous Loom EA build. The Loom team is looking for help to test the changes, i.e., trying out these builds with code that is known to use virtual threads and with libraries that are "very synchronized". The primary goal is to gauge both reliability and performance. Right now, the focus is on being functional and reliable. Please note that the performance for some cases isn't yet fully on par with blocking on j.u.concurrent locks and condition objects. As before, JFR events can be used to identify remaining cases of pinning, parking or blocking in a class initializer for example. The system property `jdk.tracePinnedThreads`, which used to print stack traces when threads are pinned, no longer outputs anything. Please send feedback via email to the Loom mailing list [7] (subscription required). [6] https://jdk.java.net/loom/ [7] http://mail.openjdk.org/mailman/listinfo/loom-dev > CXF produces thread pinning when using virtual threads > ------------------------------------------------------ > > Key: CXF-9028 > URL: https://issues.apache.org/jira/browse/CXF-9028 > Project: CXF > Issue Type: Bug > Reporter: Jose Antonio > Priority: Major > Attachments: image-2024-06-11-13-14-36-151.png, > image-2024-06-11-13-15-39-139.png > > > When using virtual threads, it's important to avoid the use of synchronized > objects and methods because I/O operations executed in them will pin the > virtual thread to its carrier thread, blocking the carrier thread instead of > the virtual one. > Executing some tests with a CXF client in a Tomcat server using virtual > threads I see that, if I spawn a few tens of virtual threads I get a lot of > thread pinning due to the code in > > {code:java} > PhaseInterceptorChain{code} > > In this class, there's a method that's invoked for all requests > > {code:java} > public synchronized boolean doIntercept(Message message){code} > > This method pins the virtual thread to the carrier thread for all the > duration of the request and response, which might be a lot of time and it > hinders the multithreaded applications throughput. Just changing the use of > synchronized keywords for ReentrantLocks will solve this issue. > > !image-2024-06-11-13-15-39-139.png|width=769,height=357! > -- This message was sent by Atlassian Jira (v8.20.10#820010)