[omniORB] Re:2nd invocation in case of timeouts

[Sai-Lai Lo]

This is the expected behaviour although it may not be what you expected.

What you see is a bad interaction between client call timeout and
connection reuse. The first call timeout causes the connection to be
shutdown. Because this connection is a cached one, the ORB's default
transient handler is called and it just goes ahead, reconnects and redo the
invocation.

In short, expected behaviour but not what one wants. No easy fix. May be we
can do a bit better in omniORB 4. However, it is best to avoid using call
timeout altogether if you can design your system in such a way.

Sai-Lai


>>>>> Masaaki Sekiya writes:

> Hi,
> I sent a mail before, but I have't received any reply here.
> Sorry to send same issue again, I send it with a detail.

> I wrote:
>> I'm using omniORB 3.0.2 on HP-UX11.00.
>> When a client invokes server object method with 
>> -ORBclientCallTimeOutPeriod,
>> ( which not to return for long time )
>> a server object method seems to be invoked twice.
>> 2nd invocation seems to be on the time that client timeout is expired.
>> A few seconds after 2nd invocation occured,client catches COMM_FAILURE.
>> Is this a right action ?

> This symptoms occurs in echo example.
> I slightly changed eg2_impl.cc as below.

> #include <unistd.h>
> #include <stdio.h>

> char* Echo_i::echoString(const char* mesg)
> {
>   printf("Echo_i::echoString\n");
>   sleep(10);
>   return CORBA::string_dup(mesg);
> }

> Then I started eg2_impl and eg2_clt as below.

> %eg2_impl
> %eg2_clt 'IOR:0000..' -ORBclientCallTimeOutPeriod 2

> eg2_impl displays "Echo_i::echoString" twice.
> After that, eg2_clt displays "Caught system exception COMM_FAILURE".



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