[
https://issues.apache.org/jira/browse/QPID-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216606#comment-13216606
]
Robbie Gemmell commented on QPID-3567:
--------------------------------------
Thanks for the update David.
Just as an FYI, calling message.acknowledge() on anything except a CLIENT_ACK
session is essentially a no-op, the only difference is an 'if CLIENT_ACK'
evaluation that prevents anything being done for the other acknowledgment modes.
Given that you havent seen the issue again and we havent had any other reports
or encountered it ourselves, I am just going to resolve the issue now.
Regards,
Robbie
> 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]
