[omniORB] Re: client call timeouts on Windows NT PC
Sai-Lai Lo
S.Lo@uk.research.att.com
06 Mar 2000 17:35:00 +0000
Hi! I looked into your problem this afternoon and can confirm your
observation. I believe I've done the same test on NT before and it works fine.
But now it doesn't want to play ball!!
Doing the test by changing eg2_impl not to return for a long time and
run eg2_clt with the options:
-ORBtraceLevel 25 -ORBscanGranularity 1 -ORBclientCallTimeOutPeriod 3
I can see the ORB calling shutdown on the connection after the 3 seconds
timeout but the call has absolutely no effect. The thread doing the call
stays blocking in the recv() call and the change of state of the socket has
no effect on it.
Unfortunately, I've no workaround to offer at the moment. If you are
willing to investigate further, you can look into the source:
<top>/src/lib/omniORB2/orbcore/tcpSocketMTfactory.cc. The client thread is
blocking in recv() call in ll_recv(). The internal thread that handles the
timeout call tcpSocketStrand::real_shutdown(). There might be some windows
specific magic that can make this work...
Sai-Lai
>>>>> Schuetz Andreas writes:
> To protect clients from being blocked by faulty servers or network
> connections, I tried to limit the duration of a client call using the
> omniORB::callTimeOutPeriod(omniORB::clientSide, ...) call, with appropriate
> scan granularity.
> Unfortunately, no matter what timeout I set, there is no influence on the
> client's behaviour, the call always times out after 3-4 minutes. The tests
> were made on a Windows NT PC and with omniORB version 2.8.
> Is this a known problem on Windows-NT? (I posted this question already on
> the mailing list but, unfortunately, there was no response)
--
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