Please report new issues athttps://github.com/DOCGroup
Created attachment 1079 [details] regression test for reproducing the problem TAO VERSION: 1.6.8 (svn head -r 84545) ACE VERSION: 5.6.8 HOST MACHINE and OPERATING SYSTEM: Linux 2.6.27-gentoo-r8 #1 SMP Wed Feb 18 13:46:14 CST 2009 i686 Intel(R) Xeon(TM) CPU 2.40GHz GenuineIntel GNU/Linux THE $ACE_ROOT/ace/config.h: #include <ace/config-linux.h> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU: include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features: N/A AREA/CLASS/EXAMPLE AFFECTED: ClientRequestInterceptor DOES THE PROBLEM AFFECT: EXECUTION SYNOPSIS: The client request interceptor hook method receive_exception does not get invoked on an exception thrown by the RT_EndpointSelector. DESCRIPTION: If RTCORBA is used, a transient exception is thrown by the RT_EndpointSelector when a server is not accessible (e.g. it shutdown before a client uses its IOR to contact it). I would have expected that a correctly registered and otherwise correctly working client request interceptor would get a callback to its receive_exception () method. However, since send_request is never reached in the call order, receive_exception is not triggered. This might cause problems, if applications expect to catch any exception occuring on a CORBA call. REPEAT BY: See attached testcase in RTException.zip SAMPLE FIX/WORKAROUND: Do not use RTCORBA.
Hi Friedhelm, I think what might possibly the issue is related to the changes from bug 2133. Looking at the code in TAO_Default_Endpoint_Selector::select_endpoint it looks like Johnny went eventually with code pretty close to my original proposed patch - at least I see my original comment modification in there: // If we get here, we completely failed to find an endpoint // that we know how to use. We used to throw an exception // but that would prevent any request interception points // being called. They may know how to fix the problem so // we wait to throw the exception in // Synch_Twoway_Invocation::remote_twoway and // Synch_Oneway_Invocation::remote_oneway instead. ... in place of the un-interceptable TRANSIENT that used to live there. That patch was a pretty early version however, that bug spent a long time in the wilderness. In our code here we have similar 'drop throughs' where exception throws have been removed and replaced with a similar comment in TAO_Optimized_Connection_Endpoint_Selector::select_endpoint and in TAO_RT_Invocation_Endpoint_Selector::select_endpoint_based_on_client_protocol_policy and TAO_RT_Invocation_Endpoint_Selector::select_endpoint. If you grep for '// If we get here, we' you'll find the 3 places where I mean. I think you should be safe to just remove the exception throws at that point - those exceptions will be un-interceptable and I think we finally agreed that was always a bad thing - but YMMV and I don't have time to test that, or say for definite if it will fix your problem. Probably worth a punt though if you have a test case. Hope this helps.
I applied the following changes as proposed by Simon and the regression test now passes as expected: Index: tao/RTCORBA/RT_Invocation_Endpoint_Selectors.cpp =================================================================== --- tao/RTCORBA/RT_Invocation_Endpoint_Selectors.cpp (revision 84595) +++ tao/RTCORBA/RT_Invocation_Endpoint_Selectors.cpp (working copy) @@ -49,7 +49,6 @@ // If we get here, we completely failed to find an endpoint selector // that we know how to use, so throw an exception. - throw ::CORBA::TRANSIENT (CORBA::OMGVMCID | 2, CORBA::COMPLETED_NO); } else { @@ -132,8 +131,6 @@ // If we get here, we found at least one pertinent profile, but no // usable endpoints. - throw ::CORBA::TRANSIENT (CORBA::OMGVMCID | 2, CORBA::COMPLETED_NO); - }
marked bug as fixed