[omniORB] transient exception handler and call timeout problem

[Duncan Grisby]

On Thursday 26 July, Lazar Stricevic wrote:

> We've got server/client application that is now using omniORB 4.1.0
> Problem that is bothering us is described in messages of Vladislav
> Vrtunski (April 2005) and is still present in current version of
> omniORB.

[...]
> Is this behavior considered to be a bug or not?

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. 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.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --