JDK-6614506 : jmx interop regression when Server is over JDK6 and Client over JDK5
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2007-10-09
  • Updated: 2011-01-27
  • Resolved: 2008-12-12
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 6
6Resolved
Related Reports
Duplicate :  
JDK-6614558 - jmx interop JDK5 - JDK6 issue when calling getMBeanInfo
Relates :  
JDK-6288100 - jmx interop regression starting Mustang b37 when Server is over Mustang and Client over Tiger
Relates :  
JDK-6808536 - jmx interop hangs when Server is over JDK6 and Client over JDK5
Description
A remote call to getMBeanInfo using rmi/iiop gets stuck when :
- server runs over JDK6 (GA or U5)
- client runs over JDK5 (U5 or U13)

When dumping the stack :
^\Full thread dump Java HotSpot(TM) Server VM (1.5.0_13-rev-b06 mixed mode):

"Thread-2" daemon prio=10 tid=0x085b7a40 nid=0xf waiting on condition [0xc387d000..0xc387dc28]
        at java.lang.Thread.sleep(Native Method)
        at com.sun.jmx.remote.internal.ClientCommunicatorAdmin$Checker.run(ClientCommunicatorAdmin.java:154)
        at java.lang.Thread.run(Thread.java:595)

"p: default-threadpool; w: Idle" daemon prio=10 tid=0x082ffe10 nid=0xe in Object.wait() [0xc39ab000..0xc39abca8]
        at java.lang.Object.wait(Native Method)
        - waiting on <0xf28b6f28> (a com.sun.corba.se.impl.orbutil.threadpool.WorkQueueImpl)
        at com.sun.corba.se.impl.orbutil.threadpool.WorkQueueImpl.requestWork(WorkQueueImpl.java:122)
        - locked <0xf28b6f28> (a com.sun.corba.se.impl.orbutil.threadpool.WorkQueueImpl)
        at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:388)

"SelectorThread" daemon prio=10 tid=0x082b0428 nid=0xd runnable [0xc39ed000..0xc39edb28]
        at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
        at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:164)
        at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:68)
        at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
        - locked <0xf28c0f10> (a sun.nio.ch.Util$1)
        - locked <0xf28c0f00> (a java.util.Collections$UnmodifiableSet)
        - locked <0xf28c0b58> (a sun.nio.ch.DevPollSelectorImpl)
        at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
        at com.sun.corba.se.impl.transport.SelectorImpl.run(SelectorImpl.java:249)

"Low Memory Detector" daemon prio=10 tid=0x08191fe8 nid=0xb runnable [0x00000000..0x00000000]

"CompilerThread1" daemon prio=10 tid=0x08190760 nid=0xa waiting on condition [0x00000000..0xc3bfce30]

"CompilerThread0" daemon prio=10 tid=0x0818f930 nid=0x9 waiting on condition [0x00000000..0xf7e510b0]

"AdapterThread" daemon prio=10 tid=0x0818eb00 nid=0x8 waiting on condition [0x00000000..0x00000000]

"Signal Dispatcher" daemon prio=10 tid=0x0818dd38 nid=0x7 waiting on condition [0x00000000..0x00000000]

"Finalizer" daemon prio=10 tid=0x081814f8 nid=0x6 in Object.wait() [0xf7f17000..0xf7f17ca8]
        at java.lang.Object.wait(Native Method)
        - waiting on <0xf2800ad8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0xf2800ad8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x08181008 nid=0x5 in Object.wait() [0xf7f59000..0xf7f59b28]
        at java.lang.Object.wait(Native Method)
        - waiting on <0xf28009e8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:474)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0xf28009e8> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x080744f0 nid=0x1 in Object.wait() [0x08045000..0x08046178]
        at java.lang.Object.wait(Native Method)
        - waiting on <0xf2ae27d8> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:474)
        at com.sun.corba.se.impl.transport.CorbaResponseWaitingRoomImpl.waitForResponse(CorbaResponseWaitingRoomImpl.java:140)
        - locked <0xf2ae27d8> (a java.lang.Object)
        at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.waitForResponse(SocketOrChannelConnectionImpl.java:1058)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.waitForResponse(CorbaMessageMediatorImpl.java:253)
        at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(CorbaClientRequestDispatcherImpl.java:349)
        at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:323)
        at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:129)
        at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
        at com.sun.org.omg.SendingContext._CodeBaseStub.meta(_CodeBaseStub.java:105)
        at com.sun.corba.se.impl.encoding.CachedCodeBase.meta(CachedCodeBase.java:89)
        at com.sun.corba.se.impl.io.IIOPInputStream.getOrderedDescriptions(IIOPInputStream.java:1276)
        at com.sun.corba.se.impl.io.IIOPInputStream.inputObjectUsingFVD(IIOPInputStream.java:1455)
        at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:398)
        at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
        at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
        at com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1034)
        at com.sun.corba.se.impl.encoding.CDRInputStream.read_value(CDRInputStream.java:253)
        at com.sun.jmx.remote.internal.PInputStream.read_value(Unknown Source)
        at org.omg.stub.javax.management.remote.rmi._RMIConnection_Stub.getMBeanInfo(Unknown Source)
        at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getMBeanInfo(RMIConnector.java:1031)
        at Client.main(Client.java:42)

"VM Thread" prio=10 tid=0x0817ef30 nid=0x4 runnable 

"GC task thread#0 (ParallelGC)" prio=10 tid=0x080f62f0 nid=0x2 runnable 

"GC task thread#1 (ParallelGC)" prio=10 tid=0x080f6d30 nid=0x3 runnable 

"VM Periodic Task Thread" prio=10 tid=0x080ed9e8 nid=0xc waiting on condition 


In order to reproduce, use the attached zip file of bug 6288100 that contains all java and class files and follow the steps as listed:
        In a first shell, do:
        tnameserv -ORBInitialPort 9999
        
        In a second shell, do:
        java Server
        
        In a third shell, do:
        java Client
Comments
EVALUATION We close this bug as duplicated 6614558. But as Yves found we got new trace which may tell another problem, so we will create a new bug against JMX at first.
12-12-2008
EVALUATION The bug shows in jdk6 since we changed the some JMX code in jdk6, we believe the change is correct because RMI has no problem to deal with this change between 2 versions (5 and 6), and no problem neither with iiop if we use same jdk version (5 or 6) in both server and client sides, that's why we consider that the problem is from iiop serialization between different iiop versions.
22-05-2008
EVALUATION According to the exception stack trace with server on 1.5 and client on 1.6, I think the problem is from IIOP implementation, of course we need more investigation.
21-05-2008