[QPIDJMS-505] High CPU usage through ProgressiveProviderFuture

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Not A Problem
• Affects Version/s: 0.51.0
• Component/s: qpid-jms-client
• Assignee: Unassigned
• Reporter: Mario Schlipf
• Created: 19/May/20 11:10
• Updated: 20/May/20 12:51
• Resolved: 20/May/20 12:51

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:

	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)

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.