JDK-6382377 : incorrect Exception is given to interceptor
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:orb
  • Affected Version: 5.0u4,5.0-pool
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2006-02-07
  • Updated: 2013-06-19
  • Resolved: 2008-11-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.
Other Other Other JDK 6 JDK 7
5.0u25-revFixed 5.0u26-revFixed 5.0u27Fixed 6u12 b01Fixed 7Fixed
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.


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  =
                .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)

EVALUATION http://hg.openjdk.java.net/jdk7/build/corba/rev/ff0f02a67881

EVALUATION http://hg.openjdk.java.net/jdk7/tl/corba/rev/ff0f02a67881

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 ] ###@###.###