activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: ActiveMQ JMX Questions..
Date Mon, 10 Jul 2006 14:28:40 GMT
On 7/10/06, colincrist <> wrote:
> Hi,
> I'm adding JMX support for ActiveMQ to Hermes to let you browse durable
> subscription queues, get depths, discover queues/topics on the broker and
> some other stuff.
> I've a few questions/issues on the MBeans.
> 1. "browse" operation, type=Subscription
> It returns a CompositeType[]
> There is no way to convert this to a JMS message. Is there a helper class
> anywhere as I need a JMS message interface to render from in Hermes?

I've just added to SVN trunk a browseMessages() method (or one that
takes a selector) to return a List of JMS Message objects.

> It also returns an array of all the elements - there would be some delay for
> large queues of pending durables subscriptions. Consider 10K elements.
> How about a "browseHeaders" operation that just retured the headers?

Thats an option we could add. I wonder if there's a nicer way to offer
a 'cursor' style interface over JMX

> I could
> also imagine a "browseChangesSince" that included a timestamp and returned
> me the messages added and removed from that subscription queue.

Could you use a selector I wonder to implement the timestamp range?

> These coupled with a "browse" operation that used a selector means I could
> lazily retrieve the message body based on the JMSMessageID in the header and
> minimise the load all round.
> Clearly there are timeing issues as the messages could have been consumed
> since the browse but thats fine for a monitoring app.


Am just wondering about the 'headers' version of this option. Would it
include all possible headers (including user defined ones) - which
could be quite big too - and just miss off the actual bodies? So kinda
make empty JMS Message objects just excluding the body to represent
the 'headers'?

> 2. ObjectName for a durable type
> The name is the connection clientId + "_" + the subscription name. Can I
> rely on this being stable?

Yes. Given that the pair of those are unique we shouldn't have to
change that. Another option is to use the BrokerViewMBean to query the

ObjectName[] getDurableTopicSubscribers()



View raw message