You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "David Kellum (Commented) (JIRA)" <ji...@apache.org> on 2012/02/26 02:11:48 UTC
[jira] [Commented] (QPID-3567) CPU util slowly increases/consumer
rate reduced with Java Client
[ https://issues.apache.org/jira/browse/QPID-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216602#comment-13216602 ]
David Kellum commented on QPID-3567:
------------------------------------
FWIW, We have not seen this issue with our applications again. It may be worth nothing that:
1. We were previously "double acknowledging", i.e. explicit calling acknowledge while auto acknowledge was also enabled. We have since changed to only do one or the other.
2. When originally observed we were still on qpidc 0.8 broker. We have since upgraded to 0.12.
We have just started to use 0.14 broker and client (for another app, actually) and have not seen any similar problem with that (though again, we avoid double ack.)
So I'm not sure what combination of factors lead to the issue originally, but I suspect upgrades and single acknowledgement is at least an adequate workaround.
> CPU util slowly increases/consumer rate reduced with Java Client
> ----------------------------------------------------------------
>
> Key: QPID-3567
> URL: https://issues.apache.org/jira/browse/QPID-3567
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: 0.12
> Environment: java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
> RHEL 5.6
> Broker: qpidd (qpidc) version 0.8
> Reporter: David Kellum
> Attachments: qpid-0.12-stack-samples.txt
>
>
> For several hours on initial startup, a single threaded Java consumer application processes about 120 message/sec using only ~4% of a CPU. But CPU gradually increases and eventually impedes message consumption rate.
> At this last instance I caught it utilizing 90% CPU while consumption rate had dropped to 20 messages/sec (queue filling up.) Before restaring:
> * Checked GC: nothing unusual, very little time spent in collections.
> * Took a series of stack samples, which all have the following suspect runnable thread in the same location:
> {noformat}
> "Dispatcher-Channel-0" daemon prio=10 tid=0x00002aaab0998000 nid=0x3384 runnable [0x0000000041f5e000]
> java.lang.Thread.State: RUNNABLE
> at java.util.concurrent.ConcurrentLinkedQueue.remove(ConcurrentLinkedQueue.java:432)
> at org.apache.qpid.client.AMQSession_0_10.acknowledgeMessage(AMQSession_0_10.java:259)
> at org.apache.qpid.client.BasicMessageConsumer.postDeliver(BasicMessageConsumer.java:796)
> at org.apache.qpid.client.BasicMessageConsumer_0_10.postDeliver(BasicMessageConsumer_0_10.java:448)
> at org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:726)
> at org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:167)
> {noformat}
> Its seems odd that ConcurrentLinkedQueue.remove() call could be occupying the Dispatcher thread for 3 out of 3 samples.
> I will attach the complete stack trace.
> After restarting the application it again returns to its normal high message-rate/low CPU behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org