[omniORB] multiple calls to same method
Zurek, Jan
Jan.Zurek@dresdner-bank.com
Thu, 14 Oct 1999 10:44:28 +0200
Duncan,
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. BTW the
COMM_FAILURE exception is thrown some time after the second call. I had =
a
quick view at the source code but I did not come very far. I suspect
something is wrong in a method called "setStrindIsDying"?
Why is this functionality being added anyway?
Regards
Jan Zurek
Dresdner Kleinwort Benson
J=FCrgen-Ponto-Platz 1
D-60301 Frankfurt am Main
Tel: +49 69 263 6318
Fax: +49 69 263 11454
e-mail: Jan.Zurek@dresdner-bank.com
> -----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=20
>=20
> On Wednesday 13 October, "Zurek, Jan" wrote:
>=20
> > A client calls a method of an server-object. This call is a =
blocking =3D
> > call
> > and takes a while. After approximatily 2 minutes a new (second) =
thread =3D
> > is
> > started and the method is executed again, without a calling object =
=3D
> > anywhere!
>=20
> 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.
>=20
> 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.
>=20
> Cheers,
>=20
> Duncan.
>=20
> --=20
> -- Duncan Grisby \ Research Engineer --
> -- AT&T Laboratories Cambridge --
> -- http://www.uk.research.att.com/~dpg1 --