[tao-users] TAO Callback Timeout

[Phil Mesnier]

Hi Martin,

> On Apr 28, 2015, at 6:21 AM, Winkler Martin <M.Winkler at hainzl.at> wrote:
> 
> Hello Phil,
> 
> thank you. Now the callback timeout is working.
> 

Great!

> 
> I had tried this before. I have set the RRTT policy and used the returned object reference. The problem was, that I did not duplicate the original object reference of the callback. I assume the client released that object. Thus the callback did not work. Now I duplicate the registered callback reference, store it on the server and get an object with timeout from that stored reference. Now everything works.
> 

Ah, one might reasonably assume that a method called “set_policy_override” would modify the object on which it is called, but the CORBA specification states that the method return a new reference with the modifications and leave the original reference unmodified.

>> Feel free to follow up if you have more questions.
> 
> Now that the callback is working, I have to more questions:
> 
> 1. I use one AMI Callback Object for all calls. Is this ok, or is it better to use a new object for 
> each call? 
> It can happen, that answers from the last calls are not here and the method is called again with the same
> AMI callback object. For example (pseudocode):
> 
> AMI_CallbackObject_var cb1;
> obj->sendc_methodx(cb1.in()); 
> obj->sendc_methodx(cb1.in()); //answer from first call is not here
> 
> It seems to work but i am not sure if this can lead to problems.
> 

It depends on context. Functionally it is fine to do this, but if methodx returns a value that needs to be correlated back to the state surrounding the call, you’ll have to provide a means of distinguishing the returns. Initializing per-invocation callback handlers is the best way to do that. These objects could be pooled an reused consecutively. On the other hand if methodx returns no data, there is no problem having a common callback handler.

> 
> 2. I was wondering if there a generic way to handle errors on the client object and the server callbacks. 
> 
> When a call from the client fails (an exceptions is thrown), i set the client object in a disconnected state,
> and try to reconnect the object in an extra thread to the server.
> 
> When a call on the callback fails I assume the client has crashed and remove the callback from the server. When the client
> starts again he registers the callback and everything is working again. 
> 
> This seems to be a pretty common use case to mee. 
> So is there a generic way to handle the reconnects after a failed call to the server or client?
> 

For synchronous calls, TAO can be configured to retry a call on an exception but with AMI even a client-generated COMM_FAILURE exception is delivered to the callback handler and thus requires application involvement to retry. To enable retry on exception in synchronous invocations, use the ORB_init arguments ORBForwardOn<exception>Limit <n> where <exception> is Transient, CommFailure, ObjectNotExist, InvObjref, or ReplyClosed, and n is a positive integer. These are documented in the TAO Developer’s Guide and in $TAO_ROOT/docs/Options.html.

Best regards,
Phil

--
Phil Mesnier
Principal Software Engineer and Partner,   http://www.ociweb.com
Object Computing, Inc.                     +01.314.579.0066 x225