qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ritchie <ritch...@apache.org>
Subject Re: ActiveConsumerCount vs ConsumerCount
Date Fri, 05 Feb 2010 15:58:47 GMT
Hi Jesse,
Sorry for not picking this up on qpid-users. Please see embedded responses.

On 5 February 2010 13:31, Jesse W. Hathaway <jesse@mbuki-mvuki.org> wrote:
> I posted this question to the users mailing list, but received no
> replies, perhaps the dev subscribers can provide some insight.
> I have been running into an issue where unpredictably, my java
> qpid-broker runs out of memory. I tried upgrading to 0.6 to see if it
> resolved the issue, but it seems to still be present.
> In an attempt to debug the problem I connected the QPID JMX Management
> console to the broker. What I noticed is that when only my synapse
> process was running the ActiveConsumerCount did not increase. Yet, when
> my jruby JMS client was running the ActiveConsumerCount consistently
> increased without ever decreasing.
> Questions:
>  1. What does the ActiveConsumerCount represent?

The number of connected consumers that have available space in their
prefetch buffer to receive messages.

>  2. Is it possible that the increasing of the ActiveConsumerCount is
>     causing the broker to exhaust its memory?

With out knowing more about what you are doing it is difficult to say
but certainly the broker cannot service an infinite number of

>  3. What might be the reason my jruby JMS process is causing this value
>     to increase?

I am not familiar with jruby jms (I'll try and take a look at the
weekend). Tools like spring by default will create a new session and
consumer for each message received. If jruby doing something simlar
and you are sending a lot of messages then I would expect the
behaviour you are experiencing with a large number of active

Are you using topics by chance? If you are then every one of those
consumers will be receiving a copy of the sent message which will
greatly contribute to your OOM problems.

If you have a heap dump of the broker to hand I shall put up some
details of how you can interrogate the heap to understand what has

> thanks, Jesse
> --
> There is no expedient to which man will not
> resort to avoid the real labor of thinking.
>  - Sir Joshua Reynolds
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

Martin Ritchie

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message