JDK-8139587 : ThreadMXBean.dumpAllThreads() may fail with "java.io.InvalidObjectException: Failed to invoke from(CompositeData)"
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 9-repo-jigsaw
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-10-14
  • Updated: 2018-02-23
  • Resolved: 2015-11-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9-repo-jigsawFixed
Related Reports
Relates :  
JDK-8167099 - TypeVersionMapper doesn't handle MonitorInfo correctly
Description
When running JMX client on jigsaw build and JMX server on non-jigsaw build it  becomes impossible to use 'ThreadMXBean.dumpAllThreads()'.

Any attempt ends with
```
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
	at com.sun.proxy.$Proxy0.dumpAllThreads(Unknown Source)
	at threadinfotest.ThreadInfoTest.main(ThreadInfoTest.java:36)
Caused by: java.io.InvalidObjectException: Failed to invoke from(CompositeData)
	at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory.invalidObjectException(java.management@9.0/DefaultMXBeanMappingFactory.java:1442)
	at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(java.management@9.0/DefaultMXBeanMappingFactory.java:1029)
	at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeMapping.fromNonNullOpenValue(java.management@9.0/DefaultMXBeanMappingFactory.java:927)
	at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(java.management@9.0/DefaultMXBeanMappingFactory.java:140)
	at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$ArrayMapping.fromNonNullOpenValue(java.management@9.0/DefaultMXBeanMappingFactory.java:591)
	at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(java.management@9.0/DefaultMXBeanMappingFactory.java:140)
	at com.sun.jmx.mbeanserver.ConvertingMethod.fromOpenReturnValue(java.management@9.0/ConvertingMethod.java:131)
	at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(java.management@9.0/MXBeanProxy.java:168)
	at javax.management.MBeanServerInvocationHandler.invoke(java.management@9.0/MBeanServerInvocationHandler.java:258)
	... 2 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0/Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0/NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0/DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:530)
	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0/Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0/NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0/DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:530)
	at sun.reflect.misc.MethodUtil.invoke(java.base@9.0/MethodUtil.java:261)
	at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(java.management@9.0/DefaultMXBeanMappingFactory.java:1026)
	... 9 more
Caused by: java.lang.IllegalArgumentException: Unexpected composite type for ThreadInfo
	at sun.management.ThreadInfoCompositeData.validateCompositeData(java.management@9.0/ThreadInfoCompositeData.java:449)
	at sun.management.ThreadInfoCompositeData.getInstance(java.management@9.0/ThreadInfoCompositeData.java:75)
	at java.lang.management.ThreadInfo.<init>(java.management@9.0/ThreadInfo.java:269)
	at java.lang.management.ThreadInfo.from(java.management@9.0/ThreadInfo.java:845)
	... 20 more
```

This has been caused by adding properties to StackTraceElement in JDK 9 Jigsaw (#61744adb0fa2, #a4f21cbdc2d4) without doing corresponding changes to ThreadInfoCompositeData and StackTraceElementCompositeData classes so they are able to consume CompositeData representation from older JVMs.
Comments
Pushed to jigsaw/jake: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8103705ebe2f
03-11-2015
Proposed patch for StackTraceElementCompositeData backward compatibility support.
02-11-2015
So this will fail also for non-jigsaw client trying to talk to a jigsaw VM due to different version of composite data used to transfer the result of the method call. LW = H (broken backward/forward compatibility) M (client and server must be of different versions) M (perform the operation via generic JMX interface and parse the returned composite data by hand) = P2
14-10-2015
ILW = M (regression, jigsaw) M (client and server must be of different versions) M (perform the operation via generic JMX interface and parse the returned composite data by hand) = P3
14-10-2015