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.willi...@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.
