Please report new issues athttps://github.com/DOCGroup
Dealing with collocal invocations, "location forward" raised by ServerInterceptor or servant does not take any effect, being "lost" in Object_Adapter::dispatch_servant(). The following patch closes the gap, defining out-parameter "forward_to" and return status: Index: TAO/tao/PortableServer/Object_Adapter.cpp =================================================================== RCS file: /project/cvs-repository/ACE_wrappers-repository/TAO/tao/PortableServer/Object_Adapter.cpp,v retrieving revision 1.84 diff -u -u -r1.84 Object_Adapter.cpp --- TAO/tao/PortableServer/Object_Adapter.cpp 4 Nov 2005 09:26:55 -0000 1.84 +++ TAO/tao/PortableServer/Object_Adapter.cpp 7 Nov 2005 07:46:01 -0000 @@ -359,6 +359,22 @@ do_dispatch (req, servant_upcall ACE_ENV_ARG_PARAMETER); ACE_CHECK_RETURN (result); + + // ServerInterceptor might have raised ForwardRequest + if (req.reply_status () == PortableInterceptor::LOCATION_FORWARD) + { + CORBA::Object_var tmp_forward_to = req.forward_location (); + if (CORBA::is_nil (tmp_forward_to.in ()) ) + { + ACE_THROW_RETURN (CORBA::MARSHAL(), // FIXME(fr), raise CORBA::INTERNAL? Which minor code? + TAO_Adapter::DS_FAILED); + } + else + { + forward_to = tmp_forward_to._retn (); // hand over to out parameter + result = TAO_Adapter::DS_FORWARD; + } + } } return result;
Frank, do you have a regression for this bug, seems a strange place to add the code and the handling the server interceptors is done at a different place. What is the exact use case you are addressing?
Created attachment 475 [details] w/o the patch, execution should abort in server.cpp:test_colocal()
Just attached modified version of FaultTolerance/GroupRef_Manipulation, introducing a co-local test case. On eigth CORBA-request the Server-Interceptor raises LOCATION_FORWARD which will get lost in Object_Adapter, in consequence the return value of CORBA-request is undefined, different to one of acceptable values 1 or 317.
Compile client and server using the included VC6 or GNUACE build files and then execute the test: run_test.pl
Attachment is a tar.gz
The embedded diff would fix the problem in context of colocal invocations, but in case of remote invocations the location-forward would be sent twice back to client in consequence. Needs more investigation why TAO has two codes-locations putting a Location-Forward onto Transport.
Created attachment 513 [details] TAO1777-colocal.diff.gz
The attached diff-file (03/29/06 23:18) contains a patch to handel colocal Location-Forwards and the test-extensions for GroupRef_Manipulation test. Location-Forward-Replies are not sent twice anymore. AFAICS, this patch could go into 1.5.1 as well. The central patch is: Index: tao/PortableServer/Object_Adapter.cpp =================================================================== RCS file: /project/cvs-repository/ACE_wrappers-repository/TAO/tao/PortableServer /Object_Adapter.cpp,v retrieving revision 1.89 diff -u -u -b -r1.89 Object_Adapter.cpp --- tao/PortableServer/Object_Adapter.cpp 10 Mar 2006 07:19:13 -0000 1.89 +++ tao/PortableServer/Object_Adapter.cpp 30 Mar 2006 05:09:08 -0000 @@ -361,6 +361,13 @@ ACE_CHECK_RETURN (result); } + // ServerInterceptor might have raised ForwardRequest + if (req.collocated() && req.reply_status () == PortableInterceptor::LOCATION_ FORWARD) + { + forward_to = CORBA::Object::_duplicate (req.forward_location ()); + result = TAO_Adapter::DS_FORWARD; + } + return result; }
Frank, is this fixed?
I analyzed the failing test examples/POA/Forwarding. With or without the patch the test fails on my Windows host, but runs in either case fine on my Linux host. The hosts differ in hardware, Windows is running on Single Core Centrino 2Ghz and Linux host is Single Core P3 1GHz. The error output on Windows looks like this: C:\fr\ACE_wrappers\TAO\examples\POA\Forwarding>run_test.pl doit() returned 127 doit() returned 128 doit() returned 129 Asking server to forward next time (2232|160) EXCEPTION, Exception caught in client system exception, ID 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' TAO exception, minor code = 6 (failed to recv request response; ENOENT), completed = MAYBE As far as I can see it is a timing problem and not related to the patch. The client invokes remote calls on server. In the moment the server replies the location forward it is doing an orb->shutdown(0) and terminates, without guarantee that the location-forward-reply is consumed from connection by client before the TCP-Reset occures. On my Windows machine this causes the COMM_FAILURE in client application. Uncommenting the shutdown in server code, so that client is able to read the location-forward-reply from valid connection, the test succeeds on my windows machine with patched TAO. This is the critical code: PortableServer::Servant ServantActivator::incarnate (const PortableServer::ObjectId &, PortableServer::POA_ptr ACE_ENV_ARG_DECL) ACE_THROW_SPEC ((CORBA::SystemException, PortableServer::ForwardRequest)) { // uncomment this line and instead tear down the server-processes in // run_test.pl this->orb_->shutdown (0 ACE_ENV_ARG_PARAMETER); ACE_CHECK_RETURN (0); // Throw forward exception ACE_THROW_RETURN ( PortableServer::ForwardRequest ( this->forward_to_.in ()), 0); } Comments are welcome.
Frank see bug 2067. The example you refer to is buggy, it should not shutdown the orb and then throw a forwardrequest.
reassign to Frank, he did a lot of changes in this area and know whether this is fixed or not.
Patch Committed "ChangeLogTag: Tue Aug 29 07:54:00 UTC 2006 Frank Rehberger <frehberger@prismtech.com>" Sending ChangeLog Sending orbsvcs/tests/FaultTolerance/GroupRef_Manipulation/server.cpp Sending tao/PortableServer/Object_Adapter.cpp Transmitting file data ... Committed revision 74304.
Created attachment 598 [details] final patch fixing/testing the forwarding by colocal ServerInterceptors
In NEWS-file explain user-visible implications of patch #2301 "ChangeLogTag: Wed Aug 30 04:20:00 UTC 2006 Frank Rehberger <frehberger@prismtech.com>" Sending ChangeLog Sending NEWS Transmitting file data .. Committed revision 74331.
patch has been committed, will go into TAO-1.5.3