Can I safely skip AMD invocation style response

[aozarov]

I have a service which is defined with AMD + AMI invocation style.
Client side invocation is wrapped and protected with a timeout based bail-out.
Server invocation is included with the same timeout value as an argument.
As I am using AMD I would like to disregard queued calls or service response if its time-to-live expired (as the client will not use its result). Is it safe to do so (and not return anything and not to throw any exceptions). It should be safe from the application perspective but would like to make sure that it will not cause any "leaks" in the ice framework (server side or client side).
Thanks,
Arie.

[aozarov]

I didn't get any reply so maybe my question is not clear.
In other words, I would like to know if an AMD based Servant call can be discarded and never replied to (using the AMD_XXX_YYY callback) to some requests without any side-effects of loosing resources (memory,connection,..) on either the client side or server side. In the client the invocation is done via AMI dispatching style (and waiting to the callback is protected by application level timeout).
Thx,
Arie.

[bernard]

Hi Arie,

You need to provide a response to the AMD callback; otherwise, when would Ice release this callback?

In your case, you could for example respond with an Ice::Timeout exception. If the client didn't timeout as expected, it will get an UnknownLocalException.

Best regards,
Bernard

[mes]

Hi Arie,

The Ice run time does accumulate state for each twoway request in a client. Furthermore, the Ice run time maintains counters for outgoing and incoming requests that it uses to ensure that a communicator shuts down gracefully. For example, during shutdown Ice waits for all pending outgoing and incoming requests to complete; if a server fails to send a response, it can adversely affect both the server and its clients.

At present there is no way for a client to inform the Ice run time that it is no longer interested in a reply, and neither is there a way for a server to discard a request.

One workaround is for a client to send oneway requests, and for servers to send callback requests to deliver the results. This would avoid the issues I mentioned above, but it does change the semantics somewhat.

Take care,
Mark

[aozarov]

Thanks you both, I assumed handling/releasing of the Clients callbacks may have an issue, but wanted to get affirmation. Also, wasn't sure if there is anything on the Server side that needs to be released - but now I can see the server side effect. As for client AMI callbacks, it would definitely be nice if a cancel method was provided. BTW, will passing the callback via the request be as efficient (resource,speed) as client side, AMI, callbacks?

[mes]

Originally Posted by aozarov

BTW, will passing the callback via the request be as efficient (resource,speed) as client side, AMI, callbacks?

I assume you're asking about sending a callback proxy as a parameter of a oneway request. Doing this will definitely increase the size of the client's requests; whether this increased size actually matters will depend on the application. The size of a proxy is determined by factors that are outside the control of the Ice run time, such as the object identity in the proxy, the host names for the endpoints, and so on. It's not unreasonable to expect the addition of a callback proxy to increase the message size by 100 bytes or more. For many applications this is irrelevant, but it may be important to you.

Hope that helps,
Mark