qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-3567) CPU util slowly increases/consumer rate reduced with Java Client
Date Sun, 26 Feb 2012 01:29:48 GMT

    [ 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:dev-subscribe@qpid.apache.org


Mime
View raw message