12 Replies Latest reply on Feb 22, 2002 1:53 PM by Adrian Brock

    DefaultDomain compliance/compatibility

    Adrian Brock Master

      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

        • 1. Re: DefaultDomain compliance/compatibility
          Trevor Squires Novice

          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

          • 2. Re: DefaultDomain compliance/compatibility
            Adrian Brock Master

            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

            • 3. Re: DefaultDomain compliance/compatibility
              Trevor Squires Novice

              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

              • 4. Re: DefaultDomain compliance/compatibility
                Juha Lindfors Master

                > 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

                • 5. Re: DefaultDomain compliance/compatibility
                  Adrian Brock Master

                  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

                  • 6. Re: DefaultDomain compliance/compatibility
                    Adrian Brock Master

                    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

                    • 7. Re: DefaultDomain compliance/compatibility
                      Trevor Squires Novice

                      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

                      • 8. Re: DefaultDomain compliance/compatibility
                        Adrian Brock Master

                        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

                        • 9. Re: DefaultDomain compliance/compatibility
                          Trevor Squires Novice

                          > 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

                          • 10. Re: DefaultDomain compliance/compatibility
                            Trevor Squires Novice

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

                            DOH!

                            You're right of course.

                            Trev

                            • 11. Re: DefaultDomain compliance/compatibility
                              Adrian Brock Master

                              > 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

                              • 12. Re: DefaultDomain compliance/compatibility
                                Adrian Brock Master

                                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