rabbitmq / rabbitmq-java-client

RabbitMQ Java client
https://www.rabbitmq.com/java-client.html
Other
1.23k stars 571 forks source link

Thread Pinning occurs with VirtualThreads enabled (spring boot 3) #1276

Open keydon opened 3 months ago

keydon commented 3 months ago

Describe the bug

when running a simple spring boot 3 with spring-amqp app with the debug-flag -Djdk.tracePinnedThreads=full Thread-Pinning occurs.

Thread[#60,ForkJoinPool-1-worker-9,5,CarrierThreads]
    java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(Unknown Source)
    java.base/jdk.internal.vm.Continuation.onPinned0(Unknown Source)
    java.base/java.lang.VirtualThread.park(Unknown Source)
    java.base/java.lang.System$2.parkVirtualThread(Unknown Source)
    java.base/jdk.internal.misc.VirtualThreads.park(Unknown Source)
    java.base/java.util.concurrent.locks.LockSupport.park(Unknown Source)
    java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
    java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
    java.base/java.util.concurrent.locks.ReentrantLock$Sync.lock(Unknown Source)
    java.base/java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
    java.base/jdk.internal.misc.InternalLock.lock(Unknown Source)
    java.base/java.io.BufferedOutputStream.write(Unknown Source)
    java.base/java.io.DataOutputStream.write(Unknown Source) <== monitors:1
    java.base/java.io.ByteArrayOutputStream.writeTo(Unknown Source) <== monitors:1
    com.rabbitmq.client.impl.Frame.writeTo(Frame.java:197)
    com.rabbitmq.client.impl.SocketFrameHandler.writeFrame(SocketFrameHandler.java:209)
    com.rabbitmq.client.impl.AMQConnection.writeFrame(AMQConnection.java:649)
    com.rabbitmq.client.impl.AMQCommand.transmit(AMQCommand.java:150)
    com.rabbitmq.client.impl.AMQChannel.quiescingTransmit(AMQChannel.java:503)
    com.rabbitmq.client.impl.AMQChannel.quiescingTransmit(AMQChannel.java:479)
    com.rabbitmq.client.impl.AMQChannel.quiescingRpc(AMQChannel.java:378)
    com.rabbitmq.client.impl.AMQChannel.rpc(AMQChannel.java:366)
    com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.java:305)
    com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:152)
    com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:1033)
    com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:47)
    java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
    java.base/java.lang.reflect.Method.invoke(Unknown Source)
    org.springframework.amqp.rabbit.connection.CachingConnectionFactory$CachedChannelInvocationHandler.invoke(CachingConnectionFactory.java:1204)
    jdk.proxy2/jdk.proxy2.$Proxy228.queueDeclarePassive(Unknown Source)
    org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.attemptPassiveDeclarations(BlockingQueueConsumer.java:751)
    org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.passiveDeclarations(BlockingQueueConsumer.java:650)
    org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.start(BlockingQueueConsumer.java:637)
    org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.initialize(SimpleMessageListenerContainer.java:1481)
    org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1322)
    java.base/java.lang.VirtualThread.run(Unknown Source)

Reproduction steps

  1. Spring Boot 3 with spring-amqp
  2. JDK 21
  3. spring.threads.virtual.enabled=true
  4. jvm-debug-flag -Djdk.tracePinnedThreads=full

Expected behavior

no thread pinning

Additional context

it seems the culprits are DataOutputStream & ByteArrayOutputStream.

according to this article, not all java.io classes are adjusted to be fit for project loom. not sure why though. is it possbile to use the compatible classes instead?

lukebakken commented 3 months ago

@keydon if you have time to submit a PR to implement what you suggest, it would be appreciated. We would like to see hard evidence that a change has a substantial benefit.

Our goal with this library is to make it as backwards-compatible as possible. I believe it still supports Java 8, for instance.

acogoluegnes commented 3 months ago

You can switch to NIO to see if it works better with virtual threads.

We already refactored some parts of the Java client library (e.g. using Lock instead of synchronized), but it will be hard to completely avoid some JDK classes.