CORBA connection problem if not using deployer

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?

CORBA connection problem if not using deployer

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

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:
>
>&#10;&gt;    ControlTaskServer::InitOrb( argc, argv);&#10;&gt;&#10;&gt;    ControlTaskServer::ThreadOrb();&#10;&gt;
>
>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
&#10;   // start corba and make HMI a server&#10;       ControlTaskServer::InitOrb(argc, argv);&#10;    ControlTaskServer::CreateServer( &amp;hmi );&#10;&#10;  hmi.configure();&#10;   hmiActivity.start();&#10;       ControlTaskServer::RunOrb();&#10;       hmiActivity.stop();&#10;&#10;   // cleanup &#10;        ControlTaskServer::DestroyOrb();&#10;
while GUI has
&#10;   RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);&#10;&#10;    // Find the remote HMI component&#10;   name = &quot;HMI&quot;;&#10;    try&#10;        {       &#10;           hmi = RTT::Corba::ControlTaskProxy::Create( name );&#10;        }&#10;  catch (...)&#10;        {&#10;          std::cerr &lt;&lt; &quot;CORBA system error while looking up &quot; &lt;&lt; name &lt;&lt; std::endl;   &#10;           return false;&#10;      }&#10;
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

On Thursday 09 April 2009 15:09:13 S Roderick wrote:
...
> while GUI has
> &#10;&gt;       RTT::Corba::ControlTaskProxy::InitOrb(argc, argv);&#10;&gt;&#10;&gt;    // Find the remote HMI component&#10;&gt;       name = &quot;HMI&quot;;&#10;&gt;        try&#10;&gt;    {&#10;&gt;              hmi = RTT::Corba::ControlTaskProxy::Create( name );&#10;&gt;    }&#10;&gt;      catch (...)&#10;&gt;    {&#10;&gt;              std::cerr &lt;&lt; &quot;CORBA system error while looking up &quot; &lt;&lt; name &lt;&lt; std::endl;&#10;&gt;          return false;&#10;&gt;  }&#10;&gt;
> 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:

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

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

Peter

CORBA connection problem if not using deployer

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

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?