https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #9 from Peter Soetens <peter [..] ...> 2010-02-22 12:35:01 ---
(In reply to comment #1)
> The solution is not as simple as we had discussed, and appears to be dependant
> on the actual CORBA implementation in use. :-(
>
>
> ACE/TAO appears to require additional ORB instances to be run, which RTT doesn't
> yet support. With multiple calls to ORB->run() (like in
> ControlTaskServer::ThreadOrb() ), in RTT SingleThread instances, the default
> ACE/TAO configuration should create additional connections correctly. As Peter
> mentioned in an ML posting, the ORB->run() calls need to be in RTT SingleThread
> instances and not threads created by CORBA, for Xenomai to work correctly. A
> patch for RTT is attached to start a new thread + orb->run() call, for each call
> to ControlTaskServer::ThreadOrb(). For reference, the ACE/TAO thread/connection
> policies are documented at
>
> http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/configurations....
>
> I am unable to test an ACE/TAO implementation.
>
>
> OmniORB is a different story, and is giving me trouble. By _default_ in v4.x, it
> will create multiple connections by itself. It does not appear to require the
> patch. This _will_ cause a problem Xenomai+omniORB installations, if I read
> Peter's prevous ML post on this correctly. Related omniORB thread/connection
> policies documented at
>
> http://omniorb.sourceforge.net/omni41/omniORB/omniORB008.html
>
> http://omniorb.sourceforge.net/omni41/omniORB/omniORB004.html
>
> however, I cannot get this to work. Monkeying with the
> `threadPerConnectionPolicy`, `maxGIOPConnectionPerServer` and
> `oneCallPerConnection` options has no apparent affect, though the first one does
> appear to make the 4.1 implementation less likely to shutdown cleanly. I have
> tried with and without the attached patch, as well as with one or more calls to
> orb->run() (though looking at the omniORB source, it is hard to tell whether
> anything useful actually occurs with additional calls to orb->run() ).

Ironically, I have fixed this on the 2.0 mainline when I ran into the same
problem, ie using omniorb + Xenomai. It's true that omniorb creates its own
threads, and that we can't do the multiple orb->run() calls trick. I solved
this for omniorb by inserting at various places in the CORBA servant's code
checks to see if the 'thread' was correctly initialized by Orocos. For most
os'es this results in a nop, except for Xenomai, where a rt_task_shadow is
called.

This patch does not fix your problem fully, but it's certainly a part of the
solution.

Peter

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #8 from Peter Soetens <peter [..] ...> 2010-02-22 12:34:24 ---
Created an attachment (id=588)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=588)
Partial solution to this bug

This rtt-2.0 patch checks and shadows threads that call into the data flow
functions.

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #7 from S Roderick <kiwi [dot] net [..] ...> 2010-02-12 15:14:20 ---
Is it valid to connect multiple local components to one remote component via
multiple proxies? So is this valid?

remote = ControlTaskProxy::Create("MyComponent")
remot1 = ControlTaskProxy::Create("MyComponent")
remote2 = ControlTaskProxy::Create("MyComponent")
ClientComponent comp1(...)
ClientComponent comp2(...)
ClientComponent comp3(...)
connectPorts(comp1, remote)
connectPorts(comp2, remote1)
connectPorts(comp3, remote2)

Or do you have to do it like this?

remote = ControlTaskProxy::Create("MyComponent")
ClientComponent comp1(...)
ClientComponent comp2(...)
ClientComponent comp3(...)
connectPorts(comp1, remote)
connectPorts(comp2, remote)
connectPorts(comp3, remote)

If the first is valid then we have other problems, as the first version causes
programs to not quit. Actually, they won't even start quitting out of the
taskbrowser ...

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #6 from S Roderick <kiwi [dot] net [..] ...> 2010-02-12 15:12:22 ---
Created an attachment (id=587)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=587)
Test configuration file used for omniORB

These are the options I was playing within omniORB.

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #4 from S Roderick <kiwi [dot] net [..] ...> 2010-02-12 15:10:46 ---
Created an attachment (id=585)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=585)
Client-side test program

2 of 2 test programs. See notes in deployed.cpp

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #3 from S Roderick <kiwi [dot] net [..] ...> 2010-02-12 15:10:15 ---
Created an attachment (id=584)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=584)
Deployer-side test program

1 of 2 test programs. See notes at top of deployed.cpp

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #5 from S Roderick <kiwi [dot] net [..] ...> 2010-02-12 15:11:02 ---
Created an attachment (id=586)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=586)
Build test programs with CMake

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #2 from S Roderick <kiwi [dot] net [..] ...> 2010-02-12 14:33:54 ---
Created an attachment (id=583)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=583)
Patch to start new thread with orb-run() for each
ControlTaskServer::ThreadOrb() call

I believe this will be required in ACE/TAO, but in omniORB v4.x it will have no
effect and will just cause the additional threads to block until shutdown in
run().

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=756

--- Comment #1 from S Roderick <kiwi [dot] net [..] ...> 2010-02-12 14:32:00 ---
The solution is not as simple as we had discussed, and appears to be dependant
on the actual CORBA implementation in use. :-(

ACE/TAO appears to require additional ORB instances to be run, which RTT
doesn't yet support. With multiple calls to ORB->run() (like in
ControlTaskServer::ThreadOrb() ), in RTT SingleThread instances, the default
ACE/TAO configuration should create additional connections correctly. As Peter
mentioned in an ML posting, the ORB->run() calls need to be in RTT SingleThread
instances and not threads created by CORBA, for Xenomai to work correctly. A
patch for RTT is attached to start a new thread + orb->run() call, for each
call to ControlTaskServer::ThreadOrb(). For reference, the ACE/TAO
thread/connection policies are documented at

http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/configurations....

I am unable to test an ACE/TAO implementation.

OmniORB is a different story, and is giving me trouble. By _default_ in v4.x,
it will create multiple connections by itself. It does not appear to require
the patch. This _will_ cause a problem Xenomai+omniORB installations, if I read
Peter's prevous ML post on this correctly. Related omniORB thread/connection
policies documented at

http://omniorb.sourceforge.net/omni41/omniORB/omniORB008.html

http://omniorb.sourceforge.net/omni41/omniORB/omniORB004.html

however, I cannot get this to work. Monkeying with the
`threadPerConnectionPolicy`, `maxGIOPConnectionPerServer` and
`oneCallPerConnection` options has no apparent affect, though the first one
does appear to make the 4.1 implementation less likely to shutdown cleanly. I
have tried with and without the attached patch, as well as with one or more
calls to orb->run() (though looking at the omniORB source, it is hard to tell
whether anything useful actually occurs with additional calls to orb->run() ).