Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6222961

JMX API: Monitor service should support complex types



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


      With the Monitor service, javax.management.monitor, you can only monitor an attribute of simple type. Often, the value you want to monitor is buried inside a more complex type. For example, if you are dealing with the J2EE instrumentation defined by JSR 77, then to set a monitor on a servlet's service time, you want to get the ServiceTime for the servlet and monitor serviceTime.getMaxTime(). We would like to be able to say we are monitoring ServiceTime.maxTime and have it mean that.

      The proposed change is that the "ObservedAttribute" can be a name of the form "a.b". The attribute that will be fetched using MBeanServer.getAttribute will be "a". Then, for each dot-separated element of the ObservedAttribute, we extract an item from the current value, roughly as follows:

          StringTokenizer tok = new StringTokenizer(observedAttribute, ".");
          String attrName = tok.nextToken();
          Object v = mbeanServer.getAttribute(objectName, attrName);
          while (tok.hasMoreTokens()) {
              String part = tok.nextToken();
              if (v instanceof CompositeData)
                  v = v.get(part);
                  v = getBeanProperty(v, part);
          // observed value is v

      where getBeanProperty uses Java Beans introspection to find the named property in the given object's class, so getBeanProperty(t, "name") where t is a Thread would be the same as t.getName().

      There is a possibility for incompatible change here, since it is allowed though not recommended for an attribute to contain arbitrary characters including dots in its name. In existing code, monitoring "a.b" will look for an attribute called "a.b", which could potentially exist. It might be preferable to use some unlikely characters in the name when the dots express a path as described above, for example "[a.b]" or "(a.b)".
      ###@###.### 2005-1-31 16:21:04 GMT

      Add the following paragraphs to the package documentation for
      The value being monitored can be a simple value contained within a complex type.
      For example, the MemoryMXBean defined in java.lang.management has an attribute
      HeapMemoryUsage of type MemoryUsage. To monitor the amount of used memory,
      described by the used property of MemoryUsage, you could monitor
      "HeapMemoryUsage.used". That string would be the argument to setObservedAttribute.
      The rules used to interpret an ObservedAttribute like "HeapMemoryUsage.used" are
      as follows. Suppose the string is A.e (so A would be "HeapMemoryUsage" and e
      would be "used" in the example).
      First the value of the attribute A is obtained. Call it v. A value x is extracted
      from v as follows:
              * If v is a CompositeData and if v.get(e) returns a value then x is
                that value.
              * If v is an array and e is the string "length" then x is the length
                of the array.
              * If the above rules do not produce a value, and if
                Introspector.getBeanInfo for the class of v (v.getClass()) contains
                a PropertyDescriptor with the name e, then x is the result of calling
                the property's read method on v.
      The third rule means for example that if the attribute HeapMemoryUsage is a
      MemoryUsage, monitoring "HeapMemoryUsage.used" will obtain the observed value
      by calling MemoryUsage.getUsed().
      If the ObservedAttribute contains more than one period, for example
      "ConnectionPool.connectionStats.length", then the above rules are
      applied iteratively. Here, v would initially be the value of the
      attribute ConnectionPool, and x would be derived by applying the
      above rules with e equal to "connectionStats". Then v would be set
      to this x and a new x derived by applying the rules again with e
      equal to "length".
      Although it is recommended that attribute names be valid Java identifiers,
      it is possible for an attribute to be called HeapMemoryUsage.used. This
      means that an ObservedAttribute that is HeapMemoryUsage.used could mean
      that the value to observe is either an attribute of that name, or the
      property used within an attribute called HeapMemoryUsage. So for
      compatibility reasons, when the ObservedAttribute contains a period (.),
      the monitor will check whether an attribute exists whose name is the full
      ObservedAttribute string (HeapMemoryUsage.used in the example). It does
      this by calling getMBeanInfo for the observed MBean and looking for a
      contained MBeanAttributeInfo with the given name. If one is found, then
      that is what is monitored. If more than one MBean is being observed, the
      behavior is unspecified if some of them have a HeapMemoryUsage.used attribute
      and others do not. An implementation may therefore call getMBeanInfo on just
      one of the MBeans in this case. The behavior is also unspecified if the result
      of the check changes while the monitor is active.
      ###@###.### 2005-04-14 18:11:25 GMT


          Issue Links



              lmalvent Luis-Miguel Alventosa (Inactive)
              emcmanus Eamonn McManus
              0 Vote for this issue
              0 Start watching this issue