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

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