Archived
This forum has been archived. Please start a new discussion on GitHub.
Multiple ice_response to a single AMI callback
Is it possible to use make multiple ice_response calls from the server side
in response to a single ami call?
I have a situation where I want to send log messages as they are being generated back through the callback object, but on my second ice_response
call I get an "Ice::Exception raised by AMI::callback"? I know it kind of breaks
the paradigm to be returning multiple times for a single method call.
in response to a single ami call?
I have a situation where I want to send log messages as they are being generated back through the callback object, but on my second ice_response
call I get an "Ice::Exception raised by AMI::callback"? I know it kind of breaks
the paradigm to be returning multiple times for a single method call.
0
Comments
-
Hi Kishore,
If on the server side you dispatch a request with AMD, you can only provide one response to this request (a "success" response or an exception). Passing a second response to the AMD callback results in undefined behavior, e.g. in C++ you may get a crash.
Also note that the server is totally unaware of the type of invocation used by the client (synchronous or AMI); likewise, the client is totally unaware of the type of dispatch used by the server.
Best regards,
Bernard0 -
makes sense. thanks. Wondering if there are other mechanisms better suited
to what I am trying to do. In the distributed rendering system I want to
communicate the renderers logs back to the client.
So far my client is not a "server" so doesnt expose any objects. All communication from the server to object is in response to a method
call.
Is there another way I can send the log messages back from
the server without say creating a listener object on the the client side and
making a server make calls to it?
thanks0 -
From a fundamentals point of view there are only two ways a client can find out about new changes:
#1: The client can pull new changes from a server (polling).
#2: The server can push new changes onto a client (pushing).
If you don't want to poll then you have to push. There are no other alternatives.
As to why you don't want to make your client a server I don't know... If you are worried about security, or firewalls or the like you should look at bi-directional connections.0