Mario Schlipf created QPIDJMS-505:
-------------------------------------
Summary: High CPU usage through ProgressiveProviderFuture
Key: QPIDJMS-505
URL: https://issues.apache.org/jira/browse/QPIDJMS-505
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.51.0
Reporter: Mario Schlipf
We are using QPID JMS in combination with Sping Boot so set up JMS listeners on
queues.
We are experiencing high CPU loads from the Spring listener threads, about 20%
CPU usage per thread. We have done some investigations and using a profiler,
92% of that CPU time seems to go into `sun.misc.Unsafe.park`, see below
stacktrace:
{code:java}
at sun.misc.Unsafe.park(Native Method)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
at
org.apache.qpid.jms.provider.ProgressiveProviderFuture.sync(ProgressiveProviderFuture.java:143)
at org.apache.qpid.jms.JmsConnection.pull(JmsConnection.java:910)
at org.apache.qpid.jms.JmsConnection.pull(JmsConnection.java:899)
at
org.apache.qpid.jms.JmsMessageConsumer.performPullIfRequired(JmsMessageConsumer.java:726)
at
org.apache.qpid.jms.JmsMessageConsumer.dequeue(JmsMessageConsumer.java:304)
at
org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.java:213)
at
org.springframework.jms.support.destination.JmsDestinationAccessor.receiveFromConsumer(JmsDestinationAccessor.java:132)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:418)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:303)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:257)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1190)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1180)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1077)
at java.lang.Thread.run(Thread.java:747)
{code}
We see the high CPU load also reported using a simple `top` command.
I would expect that the `Unsafe.park` puts the thread into a waiting state,
i.e. not consuming further resources.
We have migrated to ActiveMQ JMS for a test and cannot see the same CPU usage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
