United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6382377 incorrect Exception is given to interceptor
JDK-6382377 : incorrect Exception is given to interceptor

Details
Type:
Bug
Submit Date:
2006-02-07
Status:
Resolved
Updated Date:
2013-06-19
Project Name:
JDK
Resolved Date:
2008-11-14
Component:
other-libs
OS:
generic,windows_xp
Sub-Component:
corba:orb
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u4,5.0-pool
Fixed Versions:
6u12 (b01)

Related Reports
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
We're running into an issue with our clustering implementation and JDK 1.5's interceptors. (1.5.0_04 is the specific version.)

The basic problem is that if we try to get a connection to a server that's not alive, it causes a COMM_FAILURE as it should. But our cluster interceptor is told that the exception is of type UNKNOWN. We depend on getting the right type of exception to know whether or not to failover. We can failover on COMM_FAILURE, but not UNKNOWN.

Details:

From what I can tell of the code path: marshalingComplete1 in CorbaClientRequestDispatcherImpl fails, and catches a RuntimeException.

In the catch block, this code is executed:
        boolean retry  =
        getContactInfoListIterator(orb)
                .reportException(messageMediator.getContactInfo(), e);

Which returns false, because we handle the cluster list in our interceptor, instead of letting the JDK do it. So the method just re-throws the exception, instead of invoking the ClientPIEndingPoint with the right exception. The exception bubbles out to CorbaClientDelegateImpl, which then triggers releaseReply, which calls endRequest on the CorbaClientRequestDispatcherImpl.

This then calls orb.getPIHandler().cleanupClientPIRequest(); , which sends the UNKNOWN in that method to the ClientPIEndingPoint, because by this point, the original cause has been lost.

It seems incorrect for an Interceptor to be getting a different exception than the one that actually caused the connection failure in the first place.

Here is the original COMM_FAILURE stack trace:

Caused by: java.io.IOException: write not supported
    at weblogic.corba.client.cluster.DummySocket$2.write(DummySocket.java:35)
    at java.io.OutputStream.write(OutputStream.java:99)
    at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.write(SocketOrChannelConnectionImpl.java:724)
    at com.sun.corba.se.impl.encoding.CDROutputObject.writeTo(CDROutputObject.java:174)
    at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.sendWithoutLock(SocketOrChannelConnectionImpl.java:992)
    at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendFragment(BufferManagerWriteStream.java:82)
    at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendMessage(BufferManagerWriteStream.java:96)
    at com.sun.corba.se.impl.encoding.CDROutputObject.finishSendingMessage(CDROutputObject.java:144)
    at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.finishSendingRequest(CorbaMessageMediatorImpl.java:247)
    at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(CorbaClientRequestDispatcherImpl.java:342)
    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 com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:213)
    at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
    at weblogic.corba.j2ee.naming.Utils.narrowContext(Utils.java:126)


Stack trace by the time we get to the interceptor:

java.lang.Exception: Stack trace
    at java.lang.Thread.dumpStack()V(Unknown Source)
    at weblogic.corba.client.cluster.ClusterInterceptor.failOver(ClusterInterceptor.java:252)
    at weblogic.corba.client.cluster.ClusterInterceptor.receive_exception(ClusterInterceptor.java:158)
    at com.sun.corba.se.impl.interceptors.InterceptorInvoker.invokeClientInterceptorEndingPoint(InterceptorInvoker.java:339)
    at com.sun.corba.se.impl.interceptors.PIHandlerImpl.invokeClientPIEndingPoint(PIHandlerImpl.java:373)
    at com.sun.corba.se.impl.interceptors.PIHandlerImpl.cleanupClientPIRequest(PIHandlerImpl.java:453)
    at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:856)
    at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:137)
    at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:223)
    at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
    at weblogic.corba.j2ee.naming.Utils.narrowContext(Utils.java:126)

                                    

Comments
EVALUATION

This appears to be a real problem.  A fix will be difficult, as the first
write to the connection can occur anywhere in the stub: request, stub
marshalling, or the invoke method.  Your test case only shows the
invoke case, because an is_a requires only a short request message.
We will need to capture exceptions inside the marshaling code, and 
make sure that they are sent to the PIHandler in all client invocation
cases.

I think a fix may require adding a new method to PIHandler to
allow setting the exception anywhere, without otherwise affecting
the complex method call sequences in this area (but more study
will be required).  A fix will also require a careful examination
of the current PI test cases, which should be covering this
functionality.
*** (#1 of 2): [ UNSAVED ] ###@###.###


*** (#2 of 2): [ UNSAVED ] ###@###.###
                                     
2006-02-28
EVALUATION

http://hg.openjdk.java.net/jdk7/tl/corba/rev/ff0f02a67881
                                     
2010-11-30
EVALUATION

http://hg.openjdk.java.net/jdk7/build/corba/rev/ff0f02a67881
                                     
2010-12-25



Hardware and Software, Engineered to Work Together