JDK-7148504 : JMX MBeanInfo no longer guarantees equality of MBeanInfo between two identical mbeans
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2012-02-24
  • Updated: 2020-07-07
Related Reports
Relates :  
JDK-6493913 - OpenMBeanInfoSupport.equals violates parent's contract
Relates :  
JDK-7023180 - Change in specified-to-be-unspecified ordering of getDeclaredMethods causes application problems
Relates :  
JDK-6493913 - OpenMBeanInfoSupport.equals violates parent's contract
Description
JDK 7 has changed its behavior with respect to MBeanInfo 'equals()' comparisons being
true for two mbeans using the same interface definitions either loaded by two different classloaders in the same VM, or across two runs of the same JVM, or for mbeans cascaded from another jvm.

Since MBeanInfo objects are large, this causes heap exhaustion at scale.

Closer examination shows that the mbeanInfos in question have the same hashcode but have a different ordering of either attributes or operations which are each stored in arrays - meaning that the 'equals()' method is no longer returning true, making them unsharable.

Further examination shows that this is due to a change in the behavior of the JDK's reflection, which is no longer returning methods in a deterministic ordering, hence causing the MBeanInfo, which is constructed by reflection, to have its attributes and/or operations in a non-deterministic order - see 7023180
Comments
I see that this bug is about MBeanInfo created *by reflection*. So maybe we could just change the JMX introspector to sort the array before passing them to the MBeanInfo? It would not solve the general case - but would solve the reflection case - which this bug is about...
05-09-2013
I'm changing the priority of this issue to P3 (according to ILW classification) * Impact: M - increase memory usage when caching a lot of MBeanInfos * Likelihood: M - unless GC starts compacting the heap the behaviour is identical to JDK6 * Workaround: M - a viable workaround exists (described by the reporter) but means overriding some parts of the standard JMX funcionality Also, the target is moved to tbd_major since CCC and API update will be required.
05-09-2013
I believe any fix for JDK-7148504 should be considered in conjunction with JDK-6493913
04-09-2013
Even though fixing the equals() method to disregard the order of array elements and updating the doc will resolve this particular problem it might introduce others. Due to the attributes/operations/constructors/notifications being accessible as arrays with fixed order it might happen, when not using the element order in the equals() method, that two MBeanInfos can be marked as equal but provide a completely different attribute/operation/constructor/notification under the same index leading to errors and confusion. Ideally, the API users should not expect the attributes/operations/constructors/notifications being in any particular order - they should be accessible as a generic collection instead of an array. However, this would completely break the MBeanInfo compatibility-wise. Pre-sorting the attributes/operations/constructors/notifications upon creating an MBeanInfo instance will resolve the problems with unpredictable method order generated by reflection in JDK7+ and will keep MBeanInfo instances truly equal (eg. accessing operations[i] will yield the same result for all the equal MBeanInfo instances)
03-01-2013
EVALUATION I would recommend that the JMX code to create an MBeanInfo by reflection be updated to sort the attributeInfos, operationInfos and constructorInfos arrays so that the equality of MBeanInfos for the same MBean interface remains true. Note that for ops-center this is not a blocker since we are working around this change by overriding the generation of MbeanInfo ourselves to regenerate the MBeanInfos with the above re-ordering - however it still affects the mbeans not generated by ops-center.
24-02-2012