JDK-6269021 : 1.4.2xx only: org.omg.CORBA.OBJECT_NOT_EXIST errors when using -Dcom.sun.CORBA.ORBServerPort
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:orb
  • Affected Version: 1.4.2_08
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: x86
  • Submitted: 2005-05-11
  • Updated: 2010-07-30
  • Resolved: 2005-07-26
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.
Other
1.4.2_10 b01Fixed
Description
BEA  WebLogic Server 8.1SP2 Solaris 8

-Customer is using -Dcom.sun.CORBA.ORBServerPort flag to bind to a port
-Once the remote application is rebooted the invoking the method causes
the error

-Dcom.sun.CORBA.ORBServerPort setting is causing the error. This setting
was  used by BEA to bind rmi-iiop objects to certain port.   

java.rmi.MarshalException: ; nested exception is: 
        org.omg.CORBA.BAD_PARAM:   vmcid: OMG  minor code: 23 completed: Maybe
        at weblogic.iiop.OutboundRequestImpl.sendReceive(OutboundRequestImpl.java:187)
        at weblogic.iiop.IIOPRemoteRef.invokeInternal(IIOPRemoteRef.java:209)
        at weblogic.iiop.IIOPRemoteRef.invoke(IIOPRemoteRef.java:153)
        at com.Servigistics.AutoPilot.IAutoPilotServer_IIOP_WLStub.doMethod2(Unknown Source)
        at com.Servigistics.AutoPilot.AutoPilotClient.doMethod2(AutoPilotClient.java:85)
        at jsp_servlet.__test._jspService(__test.java:127)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)




BEA engg., has looked into this and have noted the following and
subsequently concluded the WebLogic JNDI is not caching the IOR, and
hence they want to hear from Sun JDK team about this issue at this
point. This issue has caused a major pain point with one of our
customers and we would need a resolution ASAP.

The bad param exception is coming because of the following exception
thrown  by the jdk orb on the corba server side.

com.sun.corba.se.internal.iiop.ServerRequestImpl(Thread[RequestProcessor[0],5,ORB
ThreadGroup]): Sending SystemException: org.omg.CORBA.BAD_PARAM:   vmcid: OMG  minor code: 23 completed: Maybe
        at com.sun.corba.se.internal.iiop.IIOPInputStream.createWCharBTCConverter(IIOPInputStream.java:216)
        at com.sun.corba.se.internal.iiop.CDRInputStream_1_0.getWCharConverter(CDRInputStream_1_0.java:2309)
        at com.sun.corba.se.internal.iiop.CDRInputStream_1_2.read_wstring(CDRInputStream_1_2.java:68)
        at com.sun.corba.se.internal.iiop.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1050)
        at com.sun.corba.se.internal.iiop.CDRInputStream.read_value(CDRInputStream.java:293)
        at com.Servigistics.AutoPilot._Object1IIOP_Tie._invoke(_Object1IIOP_Tie.java:72)
        at com.sun.corba.se.internal.corba.ServerDelegate.dispatch(ServerDelegate.java:353)
        at com.sun.corba.se.internal.iiop.ORB.process(ORB.java:280)
        at com.sun.corba.se.internal.iiop.RequestProcessor.process(RequestProcessor.java:81)
        at com.sun.corba.se.internal.orbutil.ThreadPool$PooledThread.run(ThreadPool.java:106)

###@###.### 2005-05-11 22:08:50 GMT

Problem happens when a corba obejct-to-name binding is restarted and the client has a stale IOR from an earlier connection request. Client side is 3rd party orb and server side is Sun's orb. The problem is subsequent requests of the client, to invoke remote methods(RMI-IIOP) fail, though the client has, now, correct OR/newly fetched IOR. 


###@###.### 2005-07-19 18:17:41 GMT
Comments
WORK AROUND 1) To code 3rd party client in such a way that, it does look up every time (not to store and cache the remote Obj ref) OR Not to cache IOR 2) To use Portable object Adapters with persistent policy set 3) Not to use sun internal -D orb flags ###@###.### 2005-07-19 18:36:41 GMT
11-05-2005
SUGGESTED FIX >http://javaweb.eng/~hg120123/codesets/webrev/ ###@###.### 2005-07-19 18:36:41 GMT
11-05-2005
EVALUATION The problem is around code set negotiation b/w client and server. From problem configuration: We have studied the GIOP dumps from the server side and noted that when the problem (failure of RMI on subsequent calls after restart of the server) happens, there is no codeset info. in the client request. It appears from the GIOP dumps that the client sends the codeset info only during *first* contact by client to server after server restart. But, since the client had a stale IOR, the client's request does not really get past reading the codeset info. Seems like client's thinking is that it already sent the codeset info, hence will not send it again, unless a new connection is created. Ideally, for the problem scenario, upon first contact, client opens a new connection and set the codeset cache to null. Since the first request, after creating a new connection, fails because of the stale IOR that client has, the codeset cache should be still be null, which indicates the client, to send the codeset info. in the next request. But, that's not happening during the problem time, when the JSP client from weblogic trying to make RMI on the remote object. Client does not re-send the codeset info as per GIOP spec section 13.10.2.6 (most commonly) The fix is, to consume code set information first, before bailing out with an exception, as client may not resend those bytes! ###@###.### 2005-07-19 18:36:41 GMT
11-05-2005