[omniORB] client call timeouts on HP-UX

[Sai-Lai Lo]

I recently got access to an HPUX 11.00 machine and can confirm your
observation. 

What seems to happen is that on HPUX 11, whether shutdown() releases recv()
blocking in the kernel depends on which end of the connection the
socket is representing.

If the socket is passive, i.e. created by accept(), recv() is released by a
shutdown() call by another thread. Therefore the omniORB server side
connection shutdown works just fine.

If the socket is not passive, i.e. used with connect(), recv() is not
released by a shutdown() call by another thread. 

Can anyone confirm if HPUX 10 also exhibits the same behaviour?

The socket library on Windows NT also behaves in the same way.

The following code should correct the behaviour. The down side is we have
to take a performance hit in doing 2 system calls instead of 1. I just
hope poll() is not as costly as a select().

Sai-Lai


Index: tcpSocketMTfactory.cc
===================================================================
RCS file: /project/omni/cvsroot/omni/src/lib/omniORB2/orbcore/tcpSocketMTfactory.cc,v
retrieving revision 1.22.2.7
diff -c -r1.22.2.7 tcpSocketMTfactory.cc
*** tcpSocketMTfactory.cc	2000/01/27 18:09:04	1.22.2.7
--- tcpSocketMTfactory.cc	2000/06/23 13:56:44
***************
*** 190,195 ****
--- 190,199 ----
  #include <fcntl.h>
  #endif
  
+ #if defined(__hpux__)
+ #include <poll.h>
+ #endif
+ 
  #define RC_INADDR_NONE     ((CORBA::ULong)-1)
  #define RC_INVALID_SOCKET  (-1)
  #define RC_SOCKET_ERROR    (-1)
***************
*** 877,882 ****
--- 881,898 ----
  
    int rx;
    while (1) {
+ 
+ #ifdef __hpux__
+     struct pollfd fds;
+     fds.fd = pd_socket;
+     fds.events = POLLNORM;
+ 
+     while (!(rx = poll(&fds,1,omniORB::scanGranularity()*1000) > 0)) {
+       if (rx == RC_SOCKET_ERROR && errno != EINTR) 
+ 	break;
+     }
+ #endif
+ 
      if ((rx = ::recv(pd_socket,(char*)buf,sz,0)) == RC_SOCKET_ERROR) {
        if (errno == EINTR)
  	continue;




>>>>> Masaaki Sekiya writes:

> I'm using OmniORB (2.8.0) on HP-UX 11.00.
> I have problem with the client call timeouts.
> Even if a call timeouts expired , call blocking never end.
> I checked mail-archives, and I find the same issue in "2000-03/0029.html".

> As Sai-Lai wrote in this mail, I change eg2_impl not to return for a long time 
> and run eg2_clt with the options: 
> 	-ORBtraceLevel 25 -ORBscanGranularity 1 -ORBclientCallTimeOutPeriod 3

> As the result, I can see the ORB calling tcpSocketStrand::real_shutdown() 
> after the 3 seconds timeout but recv() call is still blocking.
> On my understanding , It is necesary for call timeouts that
> ::shutdown() releases ::recv() call blocking in multi-thread-mode.
> Is this understanding right ?
> In order to confirm this condition , I made a simple test application ,
> in which client one thread calls ::recv() and another thread calls ::shoutdown().
> Buf I am much more confused with the result of this test.
> If it is compiled without "-D_THREAD_SAFE" , ::shoutdown() don't release 
> ::recv() blocking. 
> ( in the distribution , there is no "-D_THREAD_SAFE" in hppa_hpux_11.00.mk )
> But it is not the solution . 
> Even if compiled with "-D_THREAD_SAFE" , 
> it does'nt make sure ::shoutdown() releases ::recv() call blocking.
> Situation changes even with adding some "cout << .. " codes.
> I wonder it is related with a multi-thread cecancellation point of ::recv() ?
> As for the test of eg2_clt , ::shoutdown() never release ::recv() blocking
> with "-D_THREAD_SAFE" or any timing.

> I can't find a next message of "2000-03/0029.html".
> Has anyone solved this problem , or Am I making something mistake ?
> Any hint would be very appliciated.




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