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