United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6269021 : 1.4.2xx only: org.omg.CORBA.OBJECT_NOT_EXIST errors when using -Dcom.sun.CORBA.ORBServerPort

Details
Type:
Bug
Submit Date:
2005-05-11
Status:
Resolved
Updated Date:
2010-07-30
Project Name:
JDK
Resolved Date:
2005-07-26
Component:
other-libs
OS:
solaris_9
Sub-Component:
corba:orb
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2_08
Fixed Versions:
1.4.2_10 (b01)

Related Reports

Sub Tasks

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
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
                                     
2005-05-11
SUGGESTED FIX

>http://javaweb.eng/~hg120123/codesets/webrev/



###@###.### 2005-07-19 18:36:41 GMT
                                     
2005-05-11
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
                                     
2005-05-11



Hardware and Software, Engineered to Work Together