[
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:[email protected]
