[
https://issues.apache.org/jira/browse/QPID-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140621#comment-13140621
]
Robbie Gemmell commented on QPID-3567:
--------------------------------------
Hi David,
It would be good if you can try 0.10 as well, to help narrow when any issue may
have been introduced. Also, trunk is about to be branched later this week in
the run up to 0.14 (currently aimed for release in around a month) and although
I cant think of anything done to fix an issue like you are describing, there
has been some change in that area so it also would be useful if you can see
whether it shows the same symptoms. If you dont have a trunk checkout handy to
roll your own, you can get a nightly build of the the client here:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Release/lastSuccessfulBuild/artifact/trunk/qpid/java/client/release/
It would also be good if you could post a simple reproducer (or failing that,
the actual code you are using now) to help anyone investigating the issue to
more closely reproduce what you are doing.
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]
