[
https://issues.apache.org/jira/browse/QPIDJMS-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Schlipf updated QPIDJMS-505:
----------------------------------
Description:
We are using QPID JMS in combination with Sping Boot to 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.
was:
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.
> 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
> Priority: Major
>
> We are using QPID JMS in combination with Sping Boot to 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]
