Hi Stephen,

Found your problem. It's a classical 'call-back-to-client' problem. If your
client program lets the server-side call back (such as serving a data port
from 'Sender' in client and calling Get() in server.), it needs to run an orb
as well. Since your client code did no run an orb, the server blocked when
calling back the client. You can fix your code by doing client-side:

#include

And instead of the usleep(...) code:

ControlTaskServer::RunOrb();

These two lines did the trick for me. Clearly, this needs to be documented.
But in your case: Receiver's Get() goes over the network each time, while
Sender's Set() is a local, real-time call.

In case Receiver should read the data in real-time, you better setup the
connection in the other direction by changing

connectPorts( &basic, receiver ) // creates the data object at basic's side.
into
connectPorts( receiver, &basic ) // creates the data object at receiver's
side.

This allows you to drop the RunOrb() again in the client code, as the client
sends the data over the network, and the server reads locally.

However, this second fix seems to reveil a bug: the server receives an
exception when the client cleans up. That's not what we want. I'll have to
dig into that.

In case you want to test corba applications, I recommend testing them first in
a single program (using both ControlTaskServer and ControlTaskProxy in
main() ), which also eases debugging. When that application works, you can
start splitting in client and server programs.

HTH,
Peter

On Friday 18 April 2008 16:02:19 S Roderick wrote:
> On Apr 17, 2008, at 11:48 , Peter Soetens wrote:
> > On Thursday 17 April 2008 16:19:57 S Roderick wrote:
> >> Ok, exactly what I needed to know. Thanks! So the trunk has working
> >> Corba/Ports now? Are there many more known problems with the Corba/
> >> Ports
> >> implementation that will be fixed for v1.6? Just trying to get an
> >> idea of
> >> what you already know are issues ... also, got any idea for a
> >> release date
> >> for v1.6? :-)
> >
> > The main reason they did not work in 1.4 was that they were not unit
> > tested
> > using CORBA. On trunk/rtt, 3 big unit tests were added testing all
> > kinds of
> > use scenarios and connections. AFAIK, It now works and behaves as
> > expected.
>
> The Corba unit tests all work for me with trunk/rtt and trunk/ocl.
> That's great! Problem is, the small Corba test client/server programs
> we wrote aren't behaving right - suspect we have something incorrectly
> setup, though no idea what. Have compared to online doc's plus the
> Corba unit tests.
>
> I've attached a zip file with the client and server test programs, and
> the output logs of each. We are simply trying to access the data ports
> of a remote task. To do this we setup a local task, connect the data
> ports of the local and remote through Corba, and then get the local
> task to update the data port (and hence the remote task). If this
> basic approach is wrong, please let me know. When we start the server,
> its periodic loop starts outputting a data value to the log. When we
> bring up the client, the remote tasks update loop stops, the client
> starts modifying the local data port value, and nothing happens at the
> server end. Huh!?
>
> We also tried this with a taskbrowser in the client, and manipulating
> the data port that way. Very sporadic results, and we found that the
> server also stopped updating once the taskbrowser was running, _but_
> the server would update whenever we did an "ls" on the taskbrowser (on
> the remote or the local task). Weird!?
>
> If using data ports is not the recommended method to get data from a
> local program (think GUI) to a remote program (think robot
> controller), then what do you recommend? NB we will be using commands,
> etc, for other data between the two programs, but the streamed data
> seems to make sense to go over a data port ....
>
> Running on Ubuntu Gutsy with Tao 1.4.7. Pulled trunk/rtt,ocl,kdl this
> morning.
>
> Any help appreciated.
> Stephen
>
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

On Friday 18 April 2008 16:02:19 S Roderick wrote:
>
> The Corba unit tests all work for me with trunk/rtt and trunk/ocl.
> That's great! Problem is, the small Corba test client/server programs
> we wrote aren't behaving right - suspect we have something incorrectly
> setup, though no idea what. Have compared to online doc's plus the
> Corba unit tests.

I can reproduce your case. Really strange. I'm on it.

Peter

>
> I've attached a zip file with the client and server test programs, and
> the output logs of each. We are simply trying to access the data ports
> of a remote task. To do this we setup a local task, connect the data
> ports of the local and remote through Corba, and then get the local
> task to update the data port (and hence the remote task). If this
> basic approach is wrong, please let me know. When we start the server,
> its periodic loop starts outputting a data value to the log. When we
> bring up the client, the remote tasks update loop stops, the client
> starts modifying the local data port value, and nothing happens at the
> server end. Huh!?
>
> We also tried this with a taskbrowser in the client, and manipulating
> the data port that way. Very sporadic results, and we found that the
> server also stopped updating once the taskbrowser was running, _but_
> the server would update whenever we did an "ls" on the taskbrowser (on
> the remote or the local task). Weird!?
>
> If using data ports is not the recommended method to get data from a
> local program (think GUI) to a remote program (think robot
> controller), then what do you recommend? NB we will be using commands,
> etc, for other data between the two programs, but the streamed data
> seems to make sense to go over a data port ....
>
> Running on Ubuntu Gutsy with Tao 1.4.7. Pulled trunk/rtt,ocl,kdl this
> morning.
>
> Any help appreciated.
> Stephen
>
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm