activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Schuller <Bill_Schul...@intuit.com>
Subject Re: PyActiveMQ: Retrieving Queue Size (Or other Queue related info)
Date Thu, 29 Jan 2009 14:07:25 GMT
I think that advisory topics are going to solve for only some of your cases.
I¹m new to AMQ, so there is a little speculation involved here. If you set
up a standard topic subscriber in python on the ActiveMQ.Advisory.FULL
topic, you will receive a message every time a destination is ³full². I¹m
assuming ³full² means that the destination has met either a hard or
policy-based soft limit and is now blocking producers. In order to determine
which destination it is, you will need to access the usageName message
header property.

As for the Producer/Consumer counts, this might be tricky. From the
documentation it looks like the message body is a Java object, but the
information you¹re looking for (producer/consumer count) is in the header,
so technically you should be able to access it by subscribing to the
appropriate topics as mentioned above. You¹ll probably want to see if you
can set up a SubscriptionRecoveryPolicy on these topics so that you¹ll
always get the most recent count.

If you are looking for the current message backlog in count or size, you¹re
looking at getting into a different game. Two avenues immediately jump to
mind.

1. use the web admin interface (no personal experience) to access these
values via HTTP from python
2. write some embedded java code (camel?) that runs in the broker, queries
the admin methods and publishes messages with the information you¹re
interested in on regular intervals.

Of course, then I start to wonder if you¹re approaching this in
architecturally the right direction. Generally the producers should always
want to produce, no mater if the consumers are offline or not consuming fast
enough. Rather than tracking how much you are using, why not set soft limits
on the destination size and have your producers block? If you need to, you
can handle this by writing to an alternate store if blocked, but this can
all be done without a lick of additional code to figure out if the
destination/broker is ³full².

Just my two and a half cents.

On 1/16/09 9:09 AM, "Jahvid.Williams" <jahvid.williams@napkasystems.com>
wrote:

>     * How Many Consumers are Connected (If none, maybe pause messages,
> probably store them in  cache or something until someone is available to
> receive them)
>     * The size of a actual queue or topic (Its quite easy to crash ActiveMQ
> with a GB or more worth of messages).

---
Bill Schuller, Service Foundations Engineering, Intuit Inc.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message