[omniORB] transient exception handler and call timeout problem

[Lazar Stricevic]

Thank you Duncan for the answer and the effort to properly implement the 
solution.

Duncan Grisby wrote:
> ...
> The behaviour is by design, although in your case it is clearly not what
> you want. In plenty of cases, you want the call timeout to be an
> absolute timeout, whatever happens and however many retries there are.
> That's what omniORB's current behaviour gives you. When a call starts, a
> deadline is set for it, and if it takes longer than that, the call is
> timed out. That's really important for (soft) real time systems, for
> example.
>
> Really, what is required is for an exception handler to choose whether
> to reset the timeout or not. That would be easy to do, by changing the
> signature of the exception handler function to return something with
> three values rather than just a boolean. That way, the options would be
> to propagate the exception, to retry within the same timeout period, or
> to retry with a new timeout period.
Solution is good. Still, does it make sense to repeat the call with same 
timeout period, if that period has already expired, i.e. would it make 
more sense to trust the exception handler and reset the timer anyway if 
the reason for it was TRANSIENT_CallTimedout ?
Reasoning for this would be that she who writes exception handler should 
be responsible enough to know what she's doing, plus it saves you the 
trouble of changing the signature of the exception handler function, 
breaking compatibility with existing code, etc.

>  Unfortunately, making that change
> now would break binary compatibility with existing code. The change
> can't be made until omniORB 4.2, when it will be acceptable to break
> binary compatibility.
>
> What I've done instead is add a new configuration parameter called
> resetTimeOutOnRetries, which is false by default. If you set it to 1
> (true), the timeout will be reset if a retry occurs, which is what you
> want. I've added it in the omni4_1_develop branch. Later this week I'm
> going to release omniORB 4.1.1, which will include this change.
>
>   
That will do perfectly for now. Thank you very much!

Regards,
Lazar