[
https://issues.apache.org/jira/browse/CXF-9028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17854048#comment-17854048
]
Andriy Redko commented on CXF-9028:
-----------------------------------
[~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)
