Still able to access component after server cleanup?

Submitted by phamelin on Mon, 2011-07-25 15:32

Hello,

I have the following code:

RTT::corba::TaskContextServer::InitOrb(argc, argv, 1.0);
RTT::corba::TaskContextServer::ThreadOrb();
 
// Create the client, the server and the proxy
RTT::TaskContext client("client");
RTT::corba::TaskContextServer* server =
RTT::corba::TaskContextServer::Create(&client, false);
RTT::corba::TaskContextProxy* proxy =
RTT::corba::TaskContextProxy::Create(RTT::corba::TaskContextServer::getIOR(&client),
true);
 
// Get the remote operation
RTT::OperationCaller<double(void)> caller =
proxy->getOperation("getPeriod");
 
// Cleanup the server
RTT::corba::TaskContextServer::CleanupServer(&client);
 
// Send the operation
RTT::SendHandle<double(void)> handle = caller.send();
 
// Collect the result
double period;
if(handle.collect(period) == RTT::SendSuccess)
   std::cout << "Got period " << period << std::endl;
 
RTT::corba::TaskContextServer::ShutdownOrb();
RTT::corba::TaskContextServer::DestroyOrb();

It seems that I am still able to succesfuly call the operation even after
the server is cleaned up. I try to perform unit tests on Corba calls while
the server is closed. It's difficult now since it likely seems that RTT
detects that I use a local server and takes a shortcut to directly call the
TaskContext operation's implementations. Am I wrong? Is there a way I can
force a CORBA timeout inside a single process? I tried to delete directly
the client TC but this lead to an assertation when I call send().

Philippe

‹ Memory leak in LocalOperationCaller using rt_allocator [Bug 882] New: Port invalidated during write() ›
»

Still able to access component after server cleanup?

Submitted by peter on Mon, 2011-07-25 21:12.

Hi Philippe,

On Mon, Jul 25, 2011 at 5:28 PM, Philippe Hamelin
<philippe [dot] hamelin [..] ...> wrote:
> Hello,
>
> I have the following code:
>
> 

> RTT::corba::TaskContextServer::InitOrb(argc, argv, 1.0);
> RTT::corba::TaskContextServer::ThreadOrb();
>
> // Create the client, the server and the proxy
> RTT::TaskContext client("client");
> RTT::corba::TaskContextServer* server =
> RTT::corba::TaskContextServer::Create(&client, false);
> RTT::corba::TaskContextProxy* proxy =
> RTT::corba::TaskContextProxy::Create(RTT::corba::TaskContextServer::getIOR(&client),
> true);
>
> // Get the remote operation
> RTT::OperationCaller<double(void)> caller =
> proxy->getOperation("getPeriod");
>
> // Cleanup the server
> RTT::corba::TaskContextServer::CleanupServer(&client);
>
> // Send the operation
> RTT::SendHandle<double(void)> handle = caller.send();
>
> // Collect the result
> double period;
> if(handle.collect(period) == RTT::SendSuccess)
>    std::cout << "Got period " << period << std::endl;
>
> RTT::corba::TaskContextServer::ShutdownOrb();
> RTT::corba::TaskContextServer::DestroyOrb();
>

>
> It seems that I am still able to succesfuly call the operation even after
> the server is cleaned up. I try to perform unit tests on Corba calls while
> the server is closed. It's difficult now since it likely seems that RTT
> detects that I use a local server and takes a shortcut to directly call the
> TaskContext operation's implementations. Am I wrong?

You're correct, we try to detect local communication and then return
the TC instead of a proxy.

> Is there a way I can
> force a CORBA timeout inside a single process? I tried to delete directly
> the client TC but this lead to an assertation when I call send().

To create a *real* proxy, take a look at how the unit tests force
using through corba instead of direct to TC.

    corba::TaskContextServer* ts = corba::TaskContextServer::Create(
tc, false ); //no-naming
    BOOST_CHECK( ts );
    TaskContext* tp = corba::TaskContextProxy::Create( ts->server(), true );
    BOOST_CHECK( tp );

Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

»

Still able to access component after server cleanup?

Submitted by phamelin on Wed, 2011-07-27 15:12.

Le lundi 25 juillet 2011, Peter Soetens <peter [..] ...> a écrit :
> Hi Philippe,
>
> On Mon, Jul 25, 2011 at 5:28 PM, Philippe Hamelin
> <philippe [dot] hamelin [..] ...> wrote:
>> Hello,
>>
>> I have the following code:
>>
>> 

>> RTT::corba::TaskContextServer::InitOrb(argc, argv, 1.0);
>> RTT::corba::TaskContextServer::ThreadOrb();
>>
>> // Create the client, the server and the proxy
>> RTT::TaskContext client("client");
>> RTT::corba::TaskContextServer* server =
>> RTT::corba::TaskContextServer::Create(&client, false);
>> RTT::corba::TaskContextProxy* proxy =
>>
RTT::corba::TaskContextProxy::Create(RTT::corba::TaskContextServer::getIOR(&client),
>> true);
>>
>> // Get the remote operation
>> RTT::OperationCaller<double(void)> caller =
>> proxy->getOperation("getPeriod");
>>
>> // Cleanup the server
>> RTT::corba::TaskContextServer::CleanupServer(&client);
>>
>> // Send the operation
>> RTT::SendHandle<double(void)> handle = caller.send();
>>
>> // Collect the result
>> double period;
>> if(handle.collect(period) == RTT::SendSuccess)
>>    std::cout << "Got period " << period << std::endl;
>>
>> RTT::corba::TaskContextServer::ShutdownOrb();
>> RTT::corba::TaskContextServer::DestroyOrb();
>>

>>
>> It seems that I am still able to succesfuly call the operation even after
>> the server is cleaned up. I try to perform unit tests on Corba calls
while
>> the server is closed. It's difficult now since it likely seems that RTT
>> detects that I use a local server and takes a shortcut to directly call
the
>> TaskContext operation's implementations. Am I wrong?
>
> You're correct, we try to detect local communication and then return
> the TC instead of a proxy.
>

I'm using the method ControlTaskProxy::Create("IOR:...", true), which is
actually:

   TaskContextProxy* TaskContextProxy::Create(std::string name, bool is_ior
/*=false*/) {
       if ( CORBA::is_nil(orb) ) {
           log(Error) << "Won't create a proxy for '"<<name<<"' : orb is
nill. Call TaskContextProxy::InitOrb(argc, argv); before
TaskContextProxy::Create()." <<endlog();
           return 0;
       }
       if ( name.empty() ) {
           log(Error) << "Can't create a proxy with an empty name."
<<endlog();
           return 0;
       }
       // create new:
       try {
           TaskContextProxy* ctp = new TaskContextProxy( name, is_ior );
           return ctp;
       }
       catch( IllegalServer& is ) {
           cerr << is.what() << endl;
       }
       return 0;
   }

As we can see, a proxy is always created. So, in theory if I destroyed the
server, how can the OperationCaller remains valid?

Philippe

»