Mixing Corba ControlTaskProxy and ControlTaskServer

Use of ControlTaskProxy in, for example, a GUI using proxies for remote components, requires use of ControlTaskServer (so that call-backs from the remote components have someone to talk to, I believe). We've been getting some odd exceptions on quitting in OmniORB, and I wanted to double check a couple of things.

1) The sequence should be this?


void Initialize()
{
RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);
RTT::Corba::ControlTaskServer::ThreadOrb();
...
try
{
hmi = RTT::Corba::ControlTaskProxy::Create( name );
}
catch (...)
{
...
}
// then connecting ports, methods, etc, from hmi back to local ports, methods
}

void Shutdown()
RTT::Corba::ControlTaskServer::ShutdownOrb(true);
RTT::Corba::ControlTaskProxy::DestroyOrb();

2) To remove the mix of both Server and Proxy classes (and any subsequent user confusion), is it basically copying the following from the ControlTaskServer implementation to the ControlTaskProxy implementation?
# the orbrunner static data member
# the OrbRunner activity
# ThreadOrb()
# RunOrb()
# the orbrunner stop/delete code of DestroyOrb(). I think that the CleanupServers() call would not occur in ControlTaskProxy?

3) Why does ControlTaskServer need orb->shutdown(), when ControlTaskProxy does not? Does this change if we do 2) above?

TIA
Stephen

Mixing Corba ControlTaskProxy and ControlTaskServer

On Tue, Aug 11, 2009 at 03:19, <kiwi [dot] net [..] ...> wrote:
> Use of ControlTaskProxy in, for example, a GUI using proxies for remote components, requires use of ControlTaskServer (so that call-backs from the remote components have someone to talk to, I believe). We've been getting some odd exceptions on quitting in OmniORB, and I wanted to double check a couple of things.

And not with TAO ? Which exceptions ? I 'only' get exceptions when I
remotely call 'shutdown()', which causes the second time ShutdownOrb()
is called to throw BAD_INV_ORDER.

>
> 1) The sequence should be this?
>
>

> void Initialize()
> {
>        RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);
>        RTT::Corba::ControlTaskServer::ThreadOrb();
> ...
>        try
>        {
>                hmi = RTT::Corba::ControlTaskProxy::Create( name );
>        }
>        catch (...)
>        {
> ...
>        }
> // then connecting ports, methods, etc, from hmi back to local ports, methods
> }
>
> void Shutdown()
>        RTT::Corba::ControlTaskServer::ShutdownOrb(true);
>        RTT::Corba::ControlTaskProxy::DestroyOrb();
> 

Yes.

>
> 2) To remove the mix of both Server and Proxy classes (and any subsequent user confusion), is it basically copying the following from the ControlTaskServer implementation to the ControlTaskProxy implementation?
> # the orbrunner static data member
> # the OrbRunner activity
> # ThreadOrb()
> # RunOrb()
> # the orbrunner stop/delete code of DestroyOrb(). I think that the CleanupServers() call would not occur in ControlTaskProxy?

Because of the strong peer-to-peer architecture, we're always ending
up with a mix of servers and proxies and as such the separation is a
bit artificial. But what we still do need is a mapping from C++->CORBA
(server) and vice versa (proxy).
We could keep the factory classes on one end and provide ORB setup etc
in one end (for example, move all that code into ApplicationSetup, or
rename that to CorbaSetup).

>
> 3) Why does ControlTaskServer need orb->shutdown(), when ControlTaskProxy does not? Does this change if we do 2) above?

Yes. Shutdown can be requested by a client. After that, the server
needs to destroy the orb.

Peter

Mixing Corba ControlTaskProxy and ControlTaskServer

On Aug 11, 2009, at 05:54 , Peter Soetens wrote:

> On Tue, Aug 11, 2009 at 03:19, <kiwi [dot] net [..] ...> wrote:
>> Use of ControlTaskProxy in, for example, a GUI using proxies for
>> remote components, requires use of ControlTaskServer (so that call-
>> backs from the remote components have someone to talk to, I
>> believe). We've been getting some odd exceptions on quitting in
>> OmniORB, and I wanted to double check a couple of things.
>
> And not with TAO ? Which exceptions ? I 'only' get exceptions when I
> remotely call 'shutdown()', which causes the second time ShutdownOrb()
> is called to throw BAD_INV_ORDER.
>
>>
>> 1) The sequence should be this?
>>
>>

>> void Initialize()
>> {
>>        RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);
>>        RTT::Corba::ControlTaskServer::ThreadOrb();
>> ...
>>        try
>>        {
>>                hmi = RTT::Corba::ControlTaskProxy::Create( name );
>>        }
>>        catch (...)
>>        {
>> ...
>>        }
>> // then connecting ports, methods, etc, from hmi back to local  
>> ports, methods
>> }
>>
>> void Shutdown()
>>        RTT::Corba::ControlTaskServer::ShutdownOrb(true);
>>        RTT::Corba::ControlTaskProxy::DestroyOrb();
>> 

>
> Yes.

And this also holds if you use "RunOrb()" instead of "ThreadOrb()",
right? The "ShutdownOrb()" call is still necessary?

Lastly, in Chapter 4, Section 2, at

http://www.orocos.org/stable/documentation/rtt/v1.8.x/doc-xml/orocos-com...

the ShutdownOrb() call isn't in the 1st example. And the 2nd example
has ControlTaskProxy::ThreadOrb() and
ControlTaskServer::ShutdownOrb(). Is that correct?

Stephen

Mixing Corba ControlTaskProxy and ControlTaskServer

On Tue, Aug 11, 2009 at 17:30, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> On Aug 11, 2009, at 05:54 , Peter Soetens wrote:
>
>> On Tue, Aug 11, 2009 at 03:19, <kiwi [dot] net [..] ...> wrote:
>>>
>>> Use of ControlTaskProxy in, for example, a GUI using proxies for remote
>>> components, requires use of ControlTaskServer (so that call-backs from the
>>> remote components have someone to talk to, I believe). We've been getting
>>> some odd exceptions on quitting in OmniORB, and I wanted to double check a
>>> couple of things.
>>
>> And not with TAO ? Which exceptions ? I 'only' get exceptions when I
>> remotely call 'shutdown()', which causes the second time ShutdownOrb()
>> is called to throw BAD_INV_ORDER.
>>
>>>
>>> 1) The sequence should be this?
>>>
>>>

>>> void Initialize()
>>> {
>>>       RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);
>>>       RTT::Corba::ControlTaskServer::ThreadOrb();
>>> ...
>>>       try
>>>       {
>>>               hmi = RTT::Corba::ControlTaskProxy::Create( name );
>>>       }
>>>       catch (...)
>>>       {
>>> ...
>>>       }
>>> // then connecting ports, methods, etc, from hmi back to local ports,
>>> methods
>>> }
>>>
>>> void Shutdown()
>>>       RTT::Corba::ControlTaskServer::ShutdownOrb(true);
>>>       RTT::Corba::ControlTaskProxy::DestroyOrb();
>>> 

>>
>> Yes.
>
> And this also holds if you use "RunOrb()" instead of "ThreadOrb()", right?

Yes.

>  The "ShutdownOrb()" call is still necessary?
>
> Lastly, in Chapter 4, Section 2, at
>
> http://www.orocos.org/stable/documentation/rtt/v1.8.x/doc-xml/orocos-com...
>
> the ShutdownOrb() call isn't in the 1st example. And the 2nd example has
> ControlTaskProxy::ThreadOrb() and ControlTaskServer::ShutdownOrb(). Is that
> correct?

IMHO the examples are correct. The first one omits ShutdownOrb because
the client code must call it (shutdown from remote); otherwise, the
RunOrb() would never have returned in the first place. The second one
does a ShutdownOrb because it reaches that line because the user
entered 'quit'. In case a remote client did a shutdown before we typed
'quit', we'll get an exception on that ShutdownOrb() line though.

Peter

Mixing Corba ControlTaskProxy and ControlTaskServer

On Aug 11, 2009, at 05:54 , Peter Soetens wrote:

> On Tue, Aug 11, 2009 at 03:19, <kiwi [dot] net [..] ...> wrote:
>> Use of ControlTaskProxy in, for example, a GUI using proxies for
>> remote components, requires use of ControlTaskServer (so that call-
>> backs from the remote components have someone to talk to, I
>> believe). We've been getting some odd exceptions on quitting in
>> OmniORB, and I wanted to double check a couple of things.
>
> And not with TAO ? Which exceptions ? I 'only' get exceptions when I
> remotely call 'shutdown()', which causes the second time ShutdownOrb()
> is called to throw BAD_INV_ORDER.

No, ACE/TAO is clean. Exact exception is

terminate called after throwing an instance of 'omni_thread_fatal'

This is from a customer and I am so far unable to replicate, hence I
wasn't about to file an Orocos bug on it yet (so it could be some
issue particular to their setup). They have omniORB @4.1.3_0+python25
from MacPorts on Mac OS X. A stack trace is attached. It only occurs
when the application is quitting. The sequence is as given in 1) in
the previous email, except it turns out we were missing
ControlTaskProxy::DestroyOrb().
>> 2) To remove the mix of both Server and Proxy classes (and any
>> subsequent user confusion), is it basically copying the following
>> from the ControlTaskServer implementation to the ControlTaskProxy
>> implementation?
>> # the orbrunner static data member
>> # the OrbRunner activity
>> # ThreadOrb()
>> # RunOrb()
>> # the orbrunner stop/delete code of DestroyOrb(). I think that the
>> CleanupServers() call would not occur in ControlTaskProxy?
>
> Because of the strong peer-to-peer architecture, we're always ending
> up with a mix of servers and proxies and as such the separation is a
> bit artificial. But what we still do need is a mapping from C++->CORBA
> (server) and vice versa (proxy).
> We could keep the factory classes on one end and provide ORB setup etc
> in one end (for example, move all that code into ApplicationSetup, or
> rename that to CorbaSetup).

Are you saying that there should be a "thread/run orb" class, separate
from ControlTaskProxy and ControlTaskServer? This orb class could be
run on each peer. Doing something like this would also allow us to
parallelize CORBA connections, which solves a CORBA problem I recently
posted about (supporting different CORBA 'channels', one for large/
slow data, and the other for small/frequent data).

>> 3) Why does ControlTaskServer need orb->shutdown(), when
>> ControlTaskProxy does not? Does this change if we do 2) above?
>
> Yes. Shutdown can be requested by a client. After that, the server
> needs to destroy the orb.

Stack trace attached.
Stephen

Mixing Corba ControlTaskProxy and ControlTaskServer

Use of ControlTaskProxy in, for example, a GUI using proxies for remote components, requires use of ControlTaskServer (so that call-backs from the remote components have someone to talk to, I believe). We've been getting some odd exceptions on quitting in OmniORB, and I wanted to double check a couple of things.

1) The sequence should be this?

void Initialize()
{
	RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);
	RTT::Corba::ControlTaskServer::ThreadOrb();
...
	try
	{	
		hmi = RTT::Corba::ControlTaskProxy::Create( name );
	}
	catch (...)
	{
...
	}
// then connecting ports, methods, etc, from hmi back to local ports, methods 
}
 
void Shutdown()
	RTT::Corba::ControlTaskServer::ShutdownOrb(true);
	RTT::Corba::ControlTaskProxy::DestroyOrb();

2) To remove the mix of both Server and Proxy classes (and any subsequent user confusion), is it basically copying the following from the ControlTaskServer implementation to the ControlTaskProxy implementation?
# the orbrunner static data member
# the OrbRunner activity
# ThreadOrb()
# RunOrb()
# the orbrunner stop/delete code of DestroyOrb(). I think that the CleanupServers() call would not occur in ControlTaskProxy?

3) Why does ControlTaskServer need orb->shutdown(), when ControlTaskProxy does not? Does this change if we do 2) above?

TIA
Stephen