MXBeans and dynamic names

[carlabramsson]

Hello!

I have a problem with the names of a certain cache-products MBeans. Look at this:

Coherence:type=Cache,service=DistributedCache,name=objectcache,nodeId=36,tier=front,loader=1729094329

Look at the last property... That is something that changes when the JVM restarts. This means that Jopr will create a new resource and mark the old one as unavailable. Is there any way to work around this with out a manual delete-add everytime the JVM restarts?

My query for the Bean is like this:

Coherence:type=Cache,service=%servicetype%,name=%name%,nodeId={localMemberId},tier=%tier%

The {localMemberId} is somthing I've hacked in myself in the discovery-bean and CoherenceService-bean. That is also a value that changes when the JVM restarts, but that value I can extract from another bean. The loader property however is only present in the objectName of the bean above.

Any idea?

BR,
Carl

[mazz]

FWIW and IMO - that's an incorrect usage of JMX and its the fault of the MBean object's implementor and managed product itself. ObjectNames that represent the same managed resource must not change everytime a managed product restarts - otherwise, they will be seen as different managed objects!

JMX is, first and foremost, a management API (aside from all the other things its used for - its main purpose in life was and is for management). And how can a management tool be able to look up and persist references to managed resources if its canonical ID (aka ObjectName) changes everytime you restart the VM??

You might be able to do realtime monitoring of a currently running process, but you can't do any persisting of data for those resources nor can you even find that same managed resource upon restart. e.g. you can't aggregate metric data across restarts because how can you relate that ObjectName 12345 is the same as ObjectName 6789? In general, how do you even know ObjectName 12345 is the same as 6789 to know they represent the identical managed resource?

IMO, you need to get the managed product to change their management API to be more friendly towards management tools :) I say that sarcastically, but its true. Those MBeans you are seeing are not designed with management tools in mind - and they can't be easily managed across restarts.

We had the same problem in JBossAS 3.x and we had them change the ObjectNames of the MDB beans because they originally had hashcodes in the ObjectNames. Same problem as what you are seeing - there was no way to easily manage them. Once they changed the ObjectNames, things worked fine.

There is no real workaround - if the managed product keeps changing the identity of their managed resources, there is nothing we can do. They look like new resources because the managed product's JMX MBeanServer is telling us they *are* different resources.

[carlabramsson]

I agree and I've banged my head against the wall a couple of times before I solved the localMemberId-issue... And then this comes along.

So, I take it that you don't have any other idea but to send a email to Cameron and ask for a change? :)

[ips]

Hi Carl,

As long as there are other attributes, besides the dynamic ones - nodeId and loader, that together make the ObjectName unique (e.g. type + service + name), then I think you could make it work. However, you would not be able to use the standard MBeanResourceDiscoveryComponent, because it uses the ObjectName as the Resource key, which would not work in your case since the resource key should remain the same across restarts of the managed app. Instead, you'd have to use something like:

Coherence:type=Cache,service=DistributedCache,name=objectcache,nodeId=*,tier=front,loader=*

or:

Coherence:type=Cache,service=DistributedCache,name=objectcache,tier=front

as your Resource key.

Note, even if you hack it up to make it work, I agree with Mazz that the MBean naming is flawed, so I think you should still submit that request to Cameron.

-Ian

[mazz]

Ian has some good points and there is possibly a workaround for you in there. Yes it would require you to write your own (or possibly extend) the MBeanResourceComponent that comes with the JMX plugin.

But it will only work if parts of the ObjectName can be used (ignoring the dynamic parts) and still have that name considered unique. You would have to first perform a JMX query on the MBean Server with the unique (and non-changing parts) of th Object name you are looking for and hope you get back a single MBean ObjectName from the JMX query. You then use that full ObjectName when actually talking to the MBean.

This requires:

a) the ObjectName is actually unique WITHOUT the parts that change upon VM-restart
b) you always query the MBeanServer when the plugin component starts because you have to get the full MBean name and you won't be guaranteed what it is until you look it up at runtime
c) you set the ResourceKey as the pseudo-ObjectName - not the full ObjectName. Jopr should only know about the unique parts of the objectname, minus the always-changing pieces.

[carlabramsson]

Tnx guys.

A couple of lines in loadBean() solved it for me... Hacked together a query.