You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by colincrist <co...@hermesjms.com> on 2006/07/10 11:31:19 UTC
ActiveMQ JMX Questions..
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?
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? I could
also imagine a "browseChangesSince" that included a timestamp and returned
me the messages added and removed from that subscription queue.
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.
2. ObjectName for a durable type
The name is the connection clientId + "_" + the subscription name. Can I
rely on this being stable?
Regards,
Colin.
--
View this message in context: http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5248649
Sent from the ActiveMQ - User forum at Nabble.com.
Re: ActiveMQ JMX Questions..
Posted by colincrist <co...@hermesjms.com>.
James.Strachan wrote:
>
>
> Thanks for the reply.
>
>> Strange. I was just looking at why we have DurableSubscriptionView and
>> InactiveDurableSubscriptionView; I don't understand why there are 2
>> classes for that. Surely being active/inactive is just a boolean flag
>> :)
>
> Agreed. Also I don't beleive the active=true/false should be in the
> ObjectName. Hermes has to construct the ObjectName dynamically from a
> topic name (for example to get pending messages depth) and should not
> have to worry about whether a consumer is active not - currently I try to
> see if the"inactive" MBean is there and if its not then I try to find the
> "active" MBean.
>
>> Does anyone know why there are 2 classes for the same thing? I'm
>> tempted to merge them.
>
> That gets my vote FWIW :)
>
>> However I don't see any more or less operations on either of these two
>> objects so don't quite follow why you see different operations?
>
> Try it with jconsole. Restart a broker that has a durable subscription.
> Look at the MBean and it will not have any operations available. Create a
> consumer for it and they appear.
>
> Finally, anyone got any thoughts on the lack of a queue MBean until the
> queue is used?
>
> Colin.
> http://hermesjms.com
>
>
>
>
>> It also seems that once connection clientID=XXX is established then all
>> Subscription MBeans become active=true even if there is only an active
>> consumer for one of them.
>
> That sounds like a JMX bug
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
View this message in context: http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5265442
Sent from the ActiveMQ - User forum at Nabble.com.
Re: ActiveMQ JMX Questions..
Posted by James Strachan <ja...@gmail.com>.
On 7/11/06, colincrist <co...@hermesjms.com> wrote:
>
>
> Just also noticed that no operations are available on the
> "Type=Subscription,active=false" MBean until the subscription turns into a
> "Type=Subscription,active=true" MBean.
Strange. I was just looking at why we have DurableSubscriptionView and
InactiveDurableSubscriptionView; I don't understand why there are 2
classes for that. Surely being active/inactive is just a boolean flag
:)
Does anyone know why there are 2 classes for the same thing? I'm
tempted to merge them.
However I don't see any more or less operations on either of these two
objects so don't quite follow why you see different operations?
> It also seems that once connection clientID=XXX is established then all
> Subscription MBeans become active=true even if there is only an active
> consumer for one of them.
That sounds like a JMX bug
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ JMX Questions..
Posted by colincrist <co...@hermesjms.com>.
Just also noticed that no operations are available on the
"Type=Subscription,active=false" MBean until the subscription turns into a
"Type=Subscription,active=true" MBean.
It also seems that once connection clientID=XXX is established then all
Subscription MBeans become active=true even if there is only an active
consumer for one of them.
Regards,
Colin.
http://hermesjms.com
--
View this message in context: http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5264116
Sent from the ActiveMQ - User forum at Nabble.com.
Re: ActiveMQ JMX Questions..
Posted by James Strachan <ja...@gmail.com>.
On 7/12/06, colincrist <co...@hermesjms.com> wrote:
> I cannot find an issue for the following so I raised one.
>
> http://issues.apache.org/activemq/browse/AMQ-819
Cool
> Is there an ETA for 4.1? I can then schedule Hermes support for about the
> same time.
Hopefully its fairly soon but there's no specific date
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ JMX Questions..
Posted by colincrist <co...@hermesjms.com>.
I cannot find an issue for the following so I raised one.
http://issues.apache.org/activemq/browse/AMQ-819
Is there an ETA for 4.1? I can then schedule Hermes support for about the
same time.
Regards,
Colin.
http://hermesjms.com
--
View this message in context: http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5289156
Sent from the ActiveMQ - User forum at Nabble.com.
Re: ActiveMQ JMX Questions..
Posted by James Strachan <ja...@gmail.com>.
Not sure what will make it into 4.1 until the release happens :). It
might be easier raising/watching the JIRAs of things you're interested
in.
On 7/12/06, colincrist <co...@hermesjms.com> wrote:
>
> James,
>
> > 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?
>
> I can implement by doing a full-refresh and comparing to what is already
> in Hermes - its no different to now, I was just looking for a possible
> optimisation.
>
> > 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).
>
> Okay, no problem.
>
> > 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.
>
> Good, thanks. Will this be in 4.1?
>
> >> 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...
> > http://issues.apache.org/activemq/browse/AMQ-812
>
> Again, thanks, will this be in 4.1?
>
> Regards,
>
> Colin.
> http://hermesjms.com
>
> --
> View this message in context: http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5288393
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ JMX Questions..
Posted by colincrist <co...@hermesjms.com>.
James,
> 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?
I can implement by doing a full-refresh and comparing to what is already
in Hermes - its no different to now, I was just looking for a possible
optimisation.
> 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).
Okay, no problem.
> 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.
Good, thanks. Will this be in 4.1?
>> 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...
> http://issues.apache.org/activemq/browse/AMQ-812
Again, thanks, will this be in 4.1?
Regards,
Colin.
http://hermesjms.com
--
View this message in context: http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5288393
Sent from the ActiveMQ - User forum at Nabble.com.
Re: ActiveMQ JMX Questions..
Posted by James Strachan <ja...@gmail.com>.
On 7/10/06, colincrist <co...@hermesjms.com> 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.
http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apache/activemq/broker/region/MessageReference.html
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:
>
> http://www.nabble.com/user-images/3179.png
>
> Note how the "SubcriptionName" is both null and incorrectly spelt.
>
> Once I've created a consumer for this durable subscription it looks like
> this:
>
> http://www.nabble.com/user-images/3180.png
>
> 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
Agreed!
> - 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...
http://issues.apache.org/activemq/browse/AMQ-812
> 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.
Great!
> 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.
--
James
-------
http://radio.weblogs.com/0112098/
Re: ActiveMQ JMX Questions..
Posted by colincrist <co...@hermesjms.com>.
Hey James,
Firstly, to reply to you comments..
> I've just added to SVN trunk a browseMessages() method (or one that
> takes a selector) to return a List of JMS Message objects.
Excellent, I'll check it out tomorrow. TVM.
>> 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.
> 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. 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.
Secondly, some other questions:
1. DurableSubscriptions
When a broker is first started, the durable "Subscription" MBean looks like
this:
http://www.nabble.com/user-images/3179.png
Note how the "SubcriptionName" is both null and incorrectly spelt.
Once I've created a consumer for this durable subscription it looks like
this:
http://www.nabble.com/user-images/3180.png
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.
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 would consider whether there is an
active consumer secondary to whether the subscription actually exists.
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.
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.
Regards,
Colin.
http://hermesjms.com
--
View this message in context: http://www.nabble.com/ActiveMQ-JMX-Questions..-tf1917262.html#a5258348
Sent from the ActiveMQ - User forum at Nabble.com.
Re: ActiveMQ JMX Questions..
Posted by James Strachan <ja...@gmail.com>.
On 7/10/06, colincrist <co...@hermesjms.com> 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.
Agreed.
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
names.
ObjectName[] getDurableTopicSubscribers()
--
James
-------
http://radio.weblogs.com/0112098/