JDK-6191561 : JCK15: api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods sometime hang
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:orb
  • Affected Version: 6.0a,5.0u2,6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: other,solaris
  • CPU: other,sparc
  • Submitted: 2004-11-05
  • Updated: 2010-04-02
  • Resolved: 2008-01-14
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 JDK 7 Other
6u2 b01Fixed 7Fixed OpenJDK6Fixed
Description
Sorry, not sure which subcategory I should use.

This test sometime pass but most of time will hang on first time. 

JDK            : 6.0 b17 
                 Fail: Tiger_u2 b04
JCK            : jck1.5
Platform[s]    : Solaris Sparc
                         x86 - passed
switch/Mode    : Default
JCK test owner : http://javaweb.eng/jck/usr/owners.jto
Failing Test   : 

api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods
api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#CMethods

Test source location:
=====================

/net/koori.sfbay/onestop/jck/1.5/latest/binaries/JCK-runtime-15/tests/api/org_omg/PortableInterceptor/ClientRequestInfo/RIMethodsTests.java


jtr file location:
==================
/net/cady/export/dtf/unified/results/mustang/b10/jck/jck-jck_runtime-suse9.1_esa-2004-11-02-09-44-40-0815/workDir/api/org_omg/PortableInterceptor/ClientRequestInfo/index_RIMethods.jtr

Note: jtr might get removed after 2 weeks.

How to reproduce:
====================

--------Script START---------------------
#!/bin/ksh
SWITCH=${1+$@}

executeClass="javasoft.sqe.tests.api.org.omg.PortableInterceptor.ClientRequestInfo.RIMethodsTests"

excludeCmd=
executeClassArgs=""
executeteTestURL=
headless=
#executeContextArgs is used for vm testing.
executeContextArgs=

#This is where you want the JDK to be use.
#Example:  JDK=/net/jdk/export/disk8/local.java/jdk1.3.1
#/usr/local/java/jdk1.4.0_beta_refresh


#This is where you want the JCK to be use.
#Example:  TESTBASE=/net/jdk/export/disk8/local.java/jck1.3a


case `uname -s` in
  SunOS|Linux)
   DRIVE=/net/cady/export
   ;;
 *)
   # Map your drive y: to \\cady\export
   DRIVE="y:"
   ;; 
esac  

TESTBASE=$DRIVE/net/koori/onestop/jck/1.5/latest/binaries
JCK=${TESTBASE}/JCK-runtime-15
JDK=$DRIVE/jdk1.6.0/promoted/all/b11/binaries/
#JDK=$DRIVE/jdk1.5.0_01/promoted/all/b05/binaries/
#JDK=$DRIVE/jdk1.5.0/latest/binaries/


case `uname -s` in
  SunOS)
   ARCH=`uname -p`
   case $ARCH in
    sparc)
      sharedJDK=$JDK/solaris-sparcv9
      ;;
    i386)
      sharedJDK=$JDK/solaris-i586
      ;;
   esac
   ;;
  Linux)
   sharedJDK=$JDK/linux-i586
   ARCH=linux
   ;;
  *)
   sharedJDK=$JDK/windows-i586
   ARCH=wintel
   ;;
esac

case `uname -s` in
 SunOS | Linux)

  CLASSPATH=${JCK}/classes:${JCK}/javatest.jar
  PATH=$sharedJDK/bin:$JDK/bin:$PATH
  ;;
 *)
  CLASSPATH="${JCK}/classes;${JCK}/javatest.jar"
  PATH="$sharedJDK/bin;$JDK/bin;$CLASSPATH;$PATH"
  ;;

esac


DISPLAY=${DISPLAY-$HOST:0.0}

if `echo $SWITCH|grep "\-d64" >/dev/null`; then
  LD_LIBRARY_PATH=${JCK}/lib/sparcv9
else
  LD_LIBRARY_PATH=${JCK}/lib/${ARCH}
fi

export PATH CLASSPATH  DISPLAY LD_LIBRARY_PATH

echo $sharedJDK
echo $CLASSPATH
java ${SWITCH} -version

((x=0))
while (( $x != 10 )) do

echo testing $x

java ${SWITCH} -verify -Xfuture -cp $CLASSPATH  -Djava.security.policy=${JCK}/lib/jck.policy  -Djava.security.auth.policy=${JCK}/lib/java.auth.policy  -Djava.security.auth.login.config=${JCK}/lib/java.login.config ${executeClass}  ${excludeCmd} ${executeClassArgs} ${executeContextArgs} ${executeteTestURL}

echo "sleep 10"
sleep 10

(( x = $x + 1 ))
done


--------Script END----------------------

Test output:
=============

Have the warning then hang.

Jan 12, 2005 1:05:44 PM com.sun.corba.se.impl.orb.ORBImpl checkShutdownState
WARNING: "IOP01210228: (BAD_OPERATION) This ORB instance has been destroyed, so no operations can be performed on it"
org.omg.CORBA.BAD_OPERATION:   vmcid: SUN  minor code: 228  completed: No
        at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbDestroyed(ORBUtilSystemException.java:586)
        at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbDestroyed(ORBUtilSystemException.java:608)
        at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1280)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1651)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1540)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:922)
        at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
        at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:694)
        at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:451)
        at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1187)
        at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:398)



Specific Machine Info:
=====================

SunOS hiltonlv 5.10 s10_74 sun4u sparc SUNW,Ultra-60

For Sol8--->
Hostname: jtg-s119(Headless)
SunOS jtg-s119 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-60


###@###.### 2004-11-05 18:37:53 GMT
###@###.### 2004-12-14 21:49:22 GMT
###@###.### 2004-12-14 21:52:10 GMT
###@###.### 2005-1-05 17:51:06 GMT
###@###.### 2005-1-12 21:10:48 GMT

Comments
EVALUATION The problem is around a small timing window that opens up between orb shutdown and register & re-creation of rootPOA. There needs to be a mutual inclusive relation and synchronization between orb shutdown and poa recreation.
13-12-2006

EVALUATION The probable cause of this problem is that ORB shutdown does not force the transport to reject new requests during shutdown. These can lead to several problems which usually result in a lost message in the ORB (acting as a server) that causes a client to hang. We need to immediately reject all new request that are received after the ORB is shut down.
15-08-2006