[
https://issues.apache.org/jira/browse/ARTEMIS-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881419#comment-17881419
]
Brian Edward Stansberry commented on ARTEMIS-4937:
--------------------------------------------------
[~jbertram] Yes, as the article says infrequent and short-lived pinning may not
be an issue[1], so case by case evaluation is appropriate.
The WildFly issue this was derived from
(https://issues.redhat.com/browse/WFLY-19566) has more info that can help with
case by case evaluation, particularly:
{quote}
See occurrences of 'onPinned' in
[https://ci.wildfly.org/repository/download/WF_MainNightlyJobs_StandardLinuxJdk21/446569:id/testsuite/integration/basic/target/wildfly/standalone/log/server.log].
Lines in the stack trace annotated with "<== monitor" show where a monitor
lock was taken that results in pinning when blocking code executes.
{quote}
I've also attached a file of lines grepped from
[https://ci.wildfly.org/repository/download/WF_MainNightlyJobs_StandardLinuxJdk21/446569:id/testsuite/integration/basic/target/wildfly/standalone/log/server.log]
that relate to Artemis. Basically the stack trace lines with "<== monitor"
where an Artemis class is being executed. That's just to give a basic sense of
how many classes/methods are involved. (The same call point can appear many
times as many different tests were executed.)
[1] Even for 'infrequent and short-lived' cases it's not ideal as applications
that run perhaps-not-highly-expert code (like WildFly running end user
deployments) that want to allow use of virtual threads will need to provide
mechanisms to make users aware when pinning occurs. Probably by listening for
JFR events and logging. Those mechanisms are likely not going to be able to
discriminate 'harmless' pinning from more concerning cases.
> Resolve virtual thread pinning issues in client side Artemis code
> -----------------------------------------------------------------
>
> Key: ARTEMIS-4937
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4937
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.35.0
> Reporter: Emmanuel Hugonnet
> Priority: Major
> Attachments: WFLY-19566-monitors.txt
>
>
> When I was testing executing WildFly workloads on a virtual thread, turning
> on JVM thread pinning logging (see WFLY-19536) revealed pinning happening in
> client-side Artemis code (e.g. sending JMS messages). This issue is to trace
> working with the Artemis community to resolve these issues and get the fixed
> code into WildFly.
> An example:
> {noformat}
> 2024-07-18 04:55:23,274 INFO [stdout] (ForkJoinPool-1-worker-1)
> Thread[#297,ForkJoinPool-1-worker-1,5,CarrierThreads]
> 2024-07-18 04:55:23,275 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:185)
> 2024-07-18 04:55:23,275 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/jdk.internal.vm.Continuation.onPinned0(Continuation.java:393)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.lang.VirtualThread.parkNanos(VirtualThread.java:631)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.lang.System$2.parkVirtualThread(System.java:2648)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:67)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:267)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:756)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1126)
> 2024-07-18 04:55:23,276 INFO [stdout] (ForkJoinPool-1-worker-1)
> java.base/java.util.concurrent.CountDownLatch.await(CountDownLatch.java:276)
> 2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
> [email protected]//org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.waitForTopology(ClientSessionFactoryImpl.java:544)
> 2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
> [email protected]//org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:773)
> 2024-07-18 04:55:23,277 INFO [stdout] (ForkJoinPool-1-worker-1)
> [email protected]//org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:913)
> <== monitors:1{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
