DefaultDomain compliance/compatibility

[adrian.brock]

Hi,

What you expect the following code to output?

MBeanServer s1 = MBeanServerFactory.createServer("s1");
ObjectInstance i1 = s1.registerMBean(new X(), ":a=b");
ObjectInstance i2 = s1.getObjectInstance(new ObjectName("s1:a=b"));
MBeanServer s2 = MBeanServerFactory.createServer("s2");
ObjectInstance i3 = s2.registerMBean(new X(), ":a=b");
System.out.println(i1.equals(i2)); // Same MBean
System.out.println(i1.equals(i3)); // Different default domains

The RI produces
false
true

All ObjectInstances except those produced by
server.queryX()
return the passed ObjectName without adding the
default domain.

Is this correct or is it an RI feature we can ignore?

Regards,
Adrian

[squirest]

Ok,

These are all just my opinion - your question isn't realy covered by the spec...

first off, I think any ObjectNames stored by the MBeanServer should be fully qualified. i.e. registering with a name ":foo=bar" should cause a new ObjectName to be created (and stored the the MBeanEntry) with the default domain filled in.

second, I believe that the MBeanRegistration.preRegister should only be given the fully qualified ObjectName.

third, I think all ObjectNames returned by the MBeanServer should be fully qualified. If we only store fq objectnames then this isn't an issue, we just return what we store.

last, an ObjectInstance from one MBeanServer is not equals() equivalent to an ObjectInstance from another MBeanServer.

Trev

[adrian.brock]

I agree.

What should I do about the last point?

I can subclass ObjectInstance for instances generated
by the server. It would include an MBeanServer reference
for comparison.
Does an ObjectInstance need to be sent between
JMX implementations? It is serializable.
Obviously, I'll have to externalize it as a
javax.management.ObjectInstance.

This isn't covered by the spec at all.
Look at the javadoc for ObjectInstance.equals(Object) :-)

Regards,
Adrian

[squirest]

Why don't we put the AgentID of the JMImplementation:type=MBeanServerDelegate into each ObjectInstance. It's a string (portable) and unique to the agent which is unique to the mbeanserver.

Trev

[juha]

> What should I do about the last point?

Add AgentID from MBean server delegate as part of the identity for object instances created by the server.

> Does an ObjectInstance need to be sent between
> JMX implementations?

yes.


-- Juha

[adrian.brock]

Ok,

I written a class

org.jboss.mx.server.ServerObjectInstance
extends javax.management.ObjectInstance

that gives the required behaviour.
MBeanServerImpl always returns one of these.

The equals(Object) method handles comparisons
between ServerObjectInstance and ObjectInstance
correctly. Just in case somebody constructs one of the
latter outside the Server.

I've still got to test what happens if you serialize it
and then deserialize in jmxri

Should I add a special compliance suite
for serialize/deserialize between JBossMX and jmxri?

Regards,
Adrian

[adrian.brock]

Back to the main default domain processing.

I've changed registerMBean and unregisterMBean
to always calculate the fully qualifed name.
This is important for validation of register/unregister
the delegate.
MBeanServer server = MBeanServerFactory.createMBeanServer("JMImplementation"); // :-)
Should this really be allowed?

I've got two solutions for the rest both store the fully
qualified name in the registry.

1) The ServerMBeanImpl calculates the fully qualified name
when registry access is required.
This is slow, but requires no special processing in the
registry.
Dynamic MBeans Default Domain: 1500 ms/100000 invocations
Standard MBeands Default Domain: 2000ms/100000 invocations

2) In the registry store a mirror registry for default
domain mbeans.
The main registry contains
DefaultDomain:foo=bar
and the mirror stores
:foo=bar
The registry then checks the mirror when it cannot find
the requested object name in the main data structure.

Dynamic MBeans Default Domain: 223 ms/100000 invocations
Standard MBeands Default Domain: 604 ms/100000 invocations

Question 1
Is the speed increase worth the extra memory consumption?

Question 2
I'm not very happy with dividing this processing between
the Server and the registry.
I could document that registry.add and registry.remove
always get a fully qualified name but other methods may
get an unqualified name.
This all assumes the registry implementation will
eventually be pluggable.

Regards,
Adrian

[squirest]

Adrian,

I'm confused as to why you've created a subclass.

What's wrong with putting the AgentID (or whatever id of the server you're using) as a private transient member of ObjectInstance?

If our ObjectInstance is going to do something beyond what the RI ObjectInstance does then whatever we do, serialisation is going to be a problem if we deserialize using jmxri. Maybe the transient marker will help here but I am a complete void as far as serialisation goes.

Trev

[adrian.brock]

javax.management.ObjectInstance is part of the
published API.

To get the AgentID into an object I need a constructor
with:

public ObjectInstance(ObjectName name, String className,
String AgentID)

I didn't think it was acceptable to add methods to
the public part of the API?

Regards,
Adrian

[squirest]

> Back to the main default domain processing.

Ok,

Sorry to do this to you.

There is a way we can do lookups without creating intermediate objects or needing duplicate contents of the registry.

Rather than keying on the ObjectName, the registry should key on String domain, String canonicalKPListString.

It could be a hash of hashes but I actually think a TST similar to what I'm doing to resolve opKEYs might be faster.

A quick hack (if we were doing hash of hashes) would be to store the defaultdomain's hash under both "" and whatever the real value is for defaultdomain.

Trev

[squirest]

>
> I didn't think it was acceptable to add methods to
> the public part of the API?

DOH!

You're right of course.

Trev

[adrian.brock]

> Sorry to do this to you.
>
> There is a way we can do lookups without creating
> intermediate objects or needing duplicate contents of
> the registry.
>
> Rather than keying on the ObjectName, the registry
> should key on String domain, String
> canonicalKPListString.
>
> It could be a hash of hashes but I actually think a
> TST similar to what I'm doing to resolve opKEYs might
> be faster.
>
> A quick hack (if we were doing hash of hashes) would
> be to store the defaultdomain's hash under both ""
> and whatever the real value is for defaultdomain.
>
> Trev

My turn to say DOH!

We already have
domain->ObjectName->Entry

I dont't need the mirror, just change to (as you suggest)
domain->canonicalKPListString->Entry

I'll leave the TST implementation as an exercise to the
reader, since you seem to be the world's leading expert :-)

Regards,
Adrian

[adrian.brock]

Ok,

I've committed the code. Maybe someone can find the 50ms.
From the profiling it looks like I'm breaking the
caching in String.hashCode() or String.equals()
I'm not sure how?

DefDom.txt is for default domain
Dom.txt is for specified domain

The output is System.err
-Xprof
and snips from
-Xrunhprof:cpu=times

Regards,
Adrian