[
https://issues.apache.org/jira/browse/QPIDJMS-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111974#comment-17111974
]
Mario Schlipf commented on QPIDJMS-505:
---------------------------------------
Thanks for your response, [~tabish]. I didn't see that this was actually
configurable.
Are you saying that this behavior is expected in the default configuration and
is required to be tweaked as needed by the user? The configuration of the
futureType also seems to be an undocumented feature and the code also doesn't
give a clear hint when to use which strategy.
Personally I rather consider this a bug since other client libraries seem not
to have this sort of issue, but I might be very well wrong since I'm also not
fully following why this type of wait cycles are needed.
Thanks
> 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]
