[omniORB] Pliiiz help me with my callback-problem
Mark Johnson
mark.johnson@onfiber.com
Fri, 5 Apr 2002 10:58:26 -0600
Charlotte,
I haven't worked with callbacks any but a string that "appears in a cryptic
manner" sounds like a it has garbage in it which makes me suspect that you
are using a string that has gone out of scope somehow by the time you are
sending it to the server. Can you verify that the string is getting copied
correctly or that its lifetime is sufficient for the callback?
-----Original Message-----
From: bjorn rohde jensen [mailto:shamus@tdcadsl.dk]
Sent: Friday, April 05, 2002 10:18 AM
To: omniorb-list@uk.research.att.com
Subject: Re: [omniORB] Pliiiz help me with my callback-problem
Hi Charlotte,
What you are trying to do should work perfectly. I am quite sure,
this is not an omniORB problem as such. Could this be a problem
with memory corruption in the C++ client? That sort of thing often
leads to odd data corruption. Try to look at the call-back servant
and check, that you are making deep copies of the IN parameters, you
want to keep. Out and return parameters are consumed by the orb, so
you might want to check, that this is handled correctly too.
Yours sincerely,
Bjorn
charlotte1@pedersen.ms wrote:
>
> Hi (I'm in desperate need......),
>
> I'm a student currently working on my diploma-thesis. The task involve
using
>
> omniorb in a client/server system that needs to run several asynchronous
>
> callbacks. The client is written in c++ and the server uses Sun's Java
ORB.
>
> The idl-interfaces below is used by the system.
>
> interface ExperimentRmiInterfaceWrapper {
>
>
>
> string getExperimentId();
>
> *** plus more methods ***
>
> };
>
> interface CyberlabRmiInterfaceWrapper {
>
>
>
> string getExperimentId();
>
> *** plus more methods ***
>
> };
>
> interface CyberlabRmiDispatcherInterfaceWrapper {
>
>
>
> CyberlabRmiInterfaceWrapper connect(
>
> in ExperimentRmiInterfaceWrapper arg0,
>
> in string arg1 );
>
>
>
> };
>
> The algorithm is as follows:
>
> **The client retrieves a <CyberlabRmiDispatcherInterfaceWrapper> object
from
>
> nameserv.
>
> **The client-object runs the connect(..) method on the server-reference,
where
>
> one of the in-parameters are a reference to a
<ExperimentRmiInterfaceWrapper>
>
> callback object.
>
> This object are created like this:
>
>
>
> // Register a CallBack object in this process.
>
> cb_i* mycallback = new cb_i();
>
> cb::CallBack_var callback = mycallback->_this(); // *implicit
activation*
>
> mycallback->_remove_ref();
>
> **The server recieves the call and invokes getExperimentId() on the
callback
>
> object. This call runs nice and the experiment-id is recieved on the
server-
>
> side. The server then dispatches a <CyberlabRmiInterfaceWrapper> object
back to
>
> the client.
>
> **The client tests a method on the new remote-refernce -> Works nice:)
>
> **The client object is alive and waits for calls to be run/recieved..
>
>
>
> **NOW the problem occurs when the server suddenly again invokes
getExperimentId
>
> () on the callback-reference. The method is triggered on the client, but
the
>
> return string appears in a cryptic manner when recieved on the server?????
>
> CAN ANYONE PLIIIIZ TELL ME WHY THIS HAPPEN....
>
> >>>> Problem: the callback-reference has a problem returning a value after
the
>
> connect(..) method has returned.
>
> In the callback-example with the distribution, the callbacks are only
performed
>
> when inside of an call initiated by the client. But then THIS ISN'T REALLY
>
> ASYNCHRONOUS CALLBACKS, AND THEN THE WHOLE POINT WITH CALLBACKS ARE LOST..
>
> What have I not understood with callbacks/omniorb???
>
> **P.S I've made a java-client and this problem doesn't occur here...
>
> **P.S2 It is not an acceptable solution to change the callback-methods to
only
>
> notify the client that it has tpo send this exper-id with another call
because
>
> the same idl is used by so many different client-implementations
(rmi-iiop,
>
> etc..)
>
> **P.S3 Can I let one register method run all through the life-time of the
>
> client (infinite...) since the callback methods then return, without
letting
>
> the processor suffer to much???
>
> I WOULD BE ENORMOUSLY PLEASED IF ANYONE COULD GIVE ME AT LEAST SOME
INFORMATION
>
> ON THIS ISSUE :-)
>
> Sincerely,
>
> Charlotte Pedersen, Norwegian University of Science and Technology
>
>