CORBA connection problem if not using deployer

Submitted by snrkiwi on Wed, 2009-04-08 12:10

We have a single component attached to a periodic activity running under a control task server. This component has several ports, and uses ControlTaskServer::RunOrb().

We have a GUI that uses a single ControlTaskProxy for the remote component, and attaches to the component's ports with a localport.connectTo(remotePort) call. As soon as the GUI attaches to the proxy's ports, the remote component's update loop halts. As soon as the GUI quits, the update continues.

We've got a similar situation that works fine when the single remote component is deployed, but instead of the GUI using a control task proxy we have a component in another deployer. Besides that, all our other systems have multiples components remotely deployed. Should there be any problem if the single component does not have any local port connections?

Demonstrated under Ubuntu Hardy and Mac OS X, both with ACE/TAO.

Any ideas?

‹ OROCOS and ROS VVV09: RobotCub Summer School Call for Participation ›
»

CORBA connection problem if not using deployer

Submitted by sspr on Wed, 2009-04-08 22:15.

On Wednesday 08 April 2009 14:18:11 kiwi [dot] net [..] ... wrote:
> We have a single component attached to a periodic activity running under a
> control task server. This component has several ports, and uses
> ControlTaskServer::RunOrb().
>
> We have a GUI that uses a single ControlTaskProxy for the remote component,
> and attaches to the component's ports with a
> localport.connectTo(remotePort) call. As soon as the GUI attaches to the
> proxy's ports, the remote component's update loop halts. As soon as the GUI
> quits, the update continues.
>
> We've got a similar situation that works fine when the single remote
> component is deployed, but instead of the GUI using a control task proxy we
> have a component in another deployer. Besides that, all our other systems
> have multiples components remotely deployed. Should there be any problem if
> the single component does not have any local port connections?
>
> Demonstrated under Ubuntu Hardy and Mac OS X, both with ACE/TAO.
>
> Any ideas?

Before I dig into this. halting components usually means that they try to call
your GUI back. Normally, this is solved by the Orocos Proxy code that sets up
a POA for handling these returning calls. What may be missing is a thread on
the proxy side that processes these call backs. See
orocos-ocl/bin/ctaskbrowser.cpp for an example, add:

    ControlTaskServer::InitOrb( argc, argv);
 
    ControlTaskServer::ThreadOrb();

to your gui code and see if the halting stops.

This is an issue many users may hit and should probably be solved by Orocos
behind the scenes. Which raises the question what the use of the Proxy code is
anyway. Why not removing the InitOrb(),... functions from the Proxy code and
forcing the user to setup a ControlTaskServer + ThreadOrb (or doing it
automatically the first time a ControlTaskProxy is created)... the setup can be
easier/fool-proof-er.

Peter

»

CORBA connection problem if not using deployer

Submitted by snrkiwi on Thu, 2009-04-09 14:15.

On Wednesday, April 08, 2009, at 10:45AM, "Peter Soetens" <peter [dot] soetens [..] ...> wrote:
>On Wednesday 08 April 2009 14:18:11 kiwi [dot] net [..] ... wrote:
>> We have a single component attached to a periodic activity running under a
>> control task server. This component has several ports, and uses
>> ControlTaskServer::RunOrb().
>>
>> We have a GUI that uses a single ControlTaskProxy for the remote component,
>> and attaches to the component's ports with a
>> localport.connectTo(remotePort) call. As soon as the GUI attaches to the
>> proxy's ports, the remote component's update loop halts. As soon as the GUI
>> quits, the update continues.
>>
>> We've got a similar situation that works fine when the single remote
>> component is deployed, but instead of the GUI using a control task proxy we
>> have a component in another deployer. Besides that, all our other systems
>> have multiples components remotely deployed. Should there be any problem if
>> the single component does not have any local port connections?
>>
>> Demonstrated under Ubuntu Hardy and Mac OS X, both with ACE/TAO.
>>
>> Any ideas?
>
>Before I dig into this. halting components usually means that they try to call
>your GUI back. Normally, this is solved by the Orocos Proxy code that sets up
>a POA for handling these returning calls. What may be missing is a thread on
>the proxy side that processes these call backs. See
>orocos-ocl/bin/ctaskbrowser.cpp for an example, add:
>
>

>    ControlTaskServer::InitOrb( argc, argv);
>
>    ControlTaskServer::ThreadOrb();
>

>
>to your gui code and see if the halting stops.
>
>This is an issue many users may hit and should probably be solved by Orocos
>behind the scenes. Which raises the question what the use of the Proxy code is
>anyway. Why not removing the InitOrb(),... functions from the Proxy code and
>forcing the user to setup a ControlTaskServer + ThreadOrb (or doing it
>automatically the first time a ControlTaskProxy is created)... the setup can be
>easier/fool-proof-er.
>
Remote component has
	// start corba and make HMI a server
	ControlTaskServer::InitOrb(argc, argv);
	ControlTaskServer::CreateServer( &hmi );
 
	hmi.configure();
	hmiActivity.start();
	ControlTaskServer::RunOrb();
	hmiActivity.stop();
 
	// cleanup 
	ControlTaskServer::DestroyOrb();

while GUI has
	RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);
 
	// Find the remote HMI component
	name = "HMI";
	try
	{	
		hmi = RTT::Corba::ControlTaskProxy::Create( name );
	}
	catch (...)
	{
		std::cerr << "CORBA system error while looking up " << name << std::endl;	
		return false;
	}

The GUI side is the same we use in multiple Orocos applications. The remote side is different in that we're not using the deployer, and it is a single component (but as mentioned previously, attaching a second component to the remote side solves the problem).

Is any of the above code incorrect?

»

CORBA connection problem if not using deployer

Submitted by sspr on Thu, 2009-04-09 20:05.

On Thursday 09 April 2009 15:09:13 S Roderick wrote:
...
> while GUI has
> 

> 	RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);
>
> 	// Find the remote HMI component
> 	name = "HMI";
> 	try
> 	{
> 		hmi = RTT::Corba::ControlTaskProxy::Create( name );
> 	}
> 	catch (...)
> 	{
> 		std::cerr << "CORBA system error while looking up " << name << std::endl;
> 		return false;
> 	}
>

> The GUI side is the same we use in multiple Orocos applications. The remote
> side is different in that we're not using the deployer, and it is a single
> component (but as mentioned previously, attaching a second component to the
> remote side solves the problem).
>
> Is any of the above code incorrect?

The GUI code isn't correct.

Change the GUI to:

	RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);
	RTT::Corba::ControlTaskServer::ThreadOrb();
 	// Find the remote HMI component
 	name = "HMI";
 	try
 	{
 		hmi = RTT::Corba::ControlTaskProxy::Create( name );
 	}
 	catch (...)
 	{
 		std::cerr << "CORBA system error while looking up " << name << std::endl;
 		return false;
 	}
 

Yes, I'm guilty, I'll change the manual.

Peter

»

CORBA connection problem if not using deployer

Submitted by snrkiwi on Wed, 2009-04-08 13:45.

On Apr 8, 2009, at 08:18 , kiwi [dot] net [..] ... wrote:

> We have a single component attached to a periodic activity running
> under a control task server. This component has several ports, and
> uses ControlTaskServer::RunOrb().
>
> We have a GUI that uses a single ControlTaskProxy for the remote
> component, and attaches to the component's ports with a
> localport.connectTo(remotePort) call. As soon as the GUI attaches to
> the proxy's ports, the remote component's update loop halts. As soon
> as the GUI quits, the update continues.
>
> We've got a similar situation that works fine when the single remote
> component is deployed, but instead of the GUI using a control task
> proxy we have a component in another deployer. Besides that, all our
> other systems have multiples components remotely deployed. Should
> there be any problem if the single component does not have any local
> port connections?
>
> Demonstrated under Ubuntu Hardy and Mac OS X, both with ACE/TAO.
>
> Any ideas?

Unit test files attached. Connecting a second component in the remote
task does make the "bug" go away (undefine "SHOW_BUG" at the top of
the file). Having just a single remote component with no local
connections seems to be the problem. I don't believe that this is an
invalid situation?

Cheers
S

»

CORBA connection problem if not using deployer

Submitted by snrkiwi on Wed, 2009-04-08 12:30.

We have a single component attached to a periodic activity running under a control task server. This component has several ports, and uses ControlTaskServer::RunOrb().

We have a GUI that uses a single ControlTaskProxy for the remote component, and attaches to the component's ports with a localport.connectTo(remotePort) call. As soon as the GUI attaches to the proxy's ports, the remote component's update loop halts. As soon as the GUI quits, the update continues.

We've got a similar situation that works fine when the single remote component is deployed, but instead of the GUI using a control task proxy we have a component in another deployer. Besides that, all our other systems have multiples components remotely deployed. Should there be any problem if the single component does not have any local port connections?

Demonstrated under Ubuntu Hardy and Mac OS X, both with ACE/TAO.

Any ideas?

»