[omniORB] multiple calls to same method

[Sai-Lai Lo]

The behaviour is caused by the ORB on the server side decided that the
upcall has taken too long and shutdown the connection. The client sees the
connection closed. Because the connection has been used more than once
successfully (the first call using the connection was GIOP LOCATE OBJECT),
the ORB throws a TRANSIENT exception and the client stub retry the call.

To be honest, I never like the idea of using timeout to get out of a
failure because one can never choose the right default timeout. This is an
example which illustrates the problem- the ORB wrongly decided that the
upcall that takes a long time to return is not gonna come back.

The fix is of course to raise the call timeout on both the client and the
server side if you know there are remote calls that will take a long time
to complete. The 2.8.0 user guide has the details.


Sai-Lai

>>>>> Wil Evers writes:

> Jan Zurek wrote :

>>> -----Original Message-----
>>> From:  Duncan Grisby [SMTP:dgrisby@uk.research.att.com]
>>> Sent:  13 October 1999 18:27
>>> To:    Zurek, Jan
>>> Cc:    omniorb-list@uk.research.att.com
>>> Subject:    Re: [omniORB] multiple calls to same method
>>> 
>>> On Wednesday 13 October, "Zurek, Jan" wrote:
>>> 
>>>> A client calls a method of an server-object.  This call is a
>>>> blocking call and takes a while.  After approximatily 2 minutes
>>>> a new (second) thread is started and the method is executed
>>>> again, without a calling object anywhere!
>> 
>>> The 2.8.0 release adds call timeouts to remote calls. By default,
>>> the client gives up on a remote call after 60 seconds; the server
>>> side gives up after 90 seconds. When a connection is closed after
>>> a timeout, the client sees a COMM_FAILURE exception. My guess is
>>> that you have a COMM_FAILURE exception handler which is
>>> automatically re-trying the invocations.
>> 
>>> You can change the timeout either with the command line arguments
>>> -ORBclientCallTimeOutPeriod and -ORBserverCallTimeOutPeriod, or
>>> using the omniORB::callTimeOutPeriod() call. If you set the timeout
>>> to zero, calls never timeout.
>> 
>> thanks for your reply.  After setting the parameters the
>> problem went away.  The interesting thing still remains:
>> we do not have an exception handler for COMM_FAILURE exception!
>> So from our code there is no retry.

> I did a similar test - on the server side, I made the first call sleep for
> two minutes.  And yes, a second call came in after one  minute.  Just like
> Jan, I did not install a user-written COMM_FAILURE handler.

> I have to say this behaviour scares me - according to the CORBA spec, an
> operation invocation has at-most-once semantics.  I can see why it makes
> sense to have a client time out after a while, but if that happens, the
> operation should not be invoked again, at least not by default.  The way
> things are now, an application tested under normal conditions would start
> to behave very strangely under heavy system loads.

> - Wil

> Wil Evers, DOOSYS IT Consultants, Maarssen, Holland





-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND