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 Tue, 11 Jul 2006 08:33:46 GMT
On 7/10/06, colincrist <> wrote:
> Hey James,
> >> 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?
> I thought that too but you only get new messages and no notification of
> consumed messages before that point in time. If you want to use it to update
> a GUI then you need to be able to remove consumed messages from some table
> model or wahtever in Swing or JavaScript. I've not tried them but are JMX
> notifications a good or bad idea for this? I think I'd like to control when
> I get data.

Getting changes since a time is a bit harder as we would have to
maintain history. The GUI knows the timestamp on each message; so if
it browses for a time-range, couldn't the absence of a message in a
queue browser imply its been consumed? i.e. remove any message in the
GUI which is not still in the queue browser?

> > 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'?
> Not really thought about the implications here, from my persective with
> Hermes, just having the JMS header properties is enough. I could then
> request to "fill in" the message later to get the rest of it.

>From ActiveMQ's perspective, we keep around a MessageReference which
just has a few details about the message.

Then you can 'fill in' the message via the getMessage() method which
will lazily load the message. The level of granularity is
MessageReference or the whole Message. There is no header/body
separation in ActiveMQ.  Or to say that another way, we have a really
small header which only includes a few core JMS headers then the rest
of the entire message is loaded efficiently in one go.

So if you wanted some way to browse the 'headers' and lazily fill in
the message detail, then a browse which returned MessageReference
would be the way to go. Though it'd be completely ActiveMQ specific
though (but then I guess using the ActiveMQ MBeans is always gonna be
ActiveMQ specific :)

> One question
> here is whether I'd be interested to know if the message has been consumed
> at this point in time. I'd probably either want to exclude consumed messages
> or get them with some additional boolean  header property such as
> JMSX_AcitiveMQ_Consumed being set.

Currently consumed messages just disappear from the browser. Its gonna
be hard to not do that, as its kinda mandated by the spec - and we
literally delete messages from queues when they are consumed (and so
they get zapped from internal caches etc).

> Secondly, some other questions:
> 1. DurableSubscriptions
> When a broker is first started, the durable "Subscription" MBean looks like
> this:
> Note how the "SubcriptionName" is both null and incorrectly spelt.
> Once I've created a consumer for this durable subscription it looks like
> this:
> See how we now have the correctly and incorrectly spelt "SubscriptionName"
> filled in. I cannot correctly "discover" existing durable subcriptions the
> way things currently work.

I'm just about to bring this up on the dev list; I don't see why we
have 2 MBeans, one for active and one for inactive durable
subscriptions; it seems to be asking for trouble - will see if we can
have this resolved ASAP.

> 2. DurableSubscriptions again
> I think the active=true/false should not be in the ObjectName. This also
> goes for the DurableTopicSubscribers and InactiveDurableTopicSubscribers
> attributes on the BrokerMBean


> - why the distinction at this level when the
> attribute is available on the MBean?

I've no idea. I think its a mistake

> I would consider whether there is an
> active consumer secondary to whether the subscription actually exists.

Agreed. A durable subscription is a durable subscription; whether its
active or not.

> 3. Lazy Queue MBean loading.
> I only see queue MBeans once a consumer first exists after a Broker startup
> even if there are messages pending. A management console needs to see all
> object with state once the broker has started.

Yeah - we need a fix for that. (Plus I'd like us to be able to specify
the destinations we want auto-creating on startup in the broker's
configuration file).

Have raised a JIRA for this...

> Happily, I've got an integration working quickly and if we can get the above
> working okay then ActiveMQ will have as functional integration with Hermes
> as its current plugin model allows.


> Next step is some cooler stuff like
> dynamically creating subscriptions, queues, topics and whatever else we can
> do via JMX.

Great! Hopefully all the methods on the mbeans (in particular
BrokerViewMBean) should be there to generate destinations &
subscriptions and to remove them again etc. Though just shout if
there's something else you need.



View raw message