[omniORB] RE: Major concurrency issue on Windows (OmniORB 4.0 .1)

[Kamaldeep Singh Khanuja]

Hi Duncan,

Please refer to the posting below.

We have increased the  value of FD_SETSIZE from 64 to 2048, which actually
delayed the problem of ORB thread hanging. I have the following suggestion
regarding the same to eliminate the ORB thread hanging, incase of no of
concurrent clients exceed the above limit, please see the following code
from SocketCollection.cc with the comments inline:

/////////////////////////////////////////////////////////////////////////
void
SocketCollection::setSelectable(SocketHandle_t sock, 
				CORBA::Boolean now,
				CORBA::Boolean data_in_buffer,
				CORBA::Boolean hold_lock) {

...
...
    if (!FD_ISSET(sock,&pd_fdset_2)) {
      pd_n_fdset_2++; // Here I see the problem that if something goes wrong
in the FD_SET, then we have already incremented the pd_n_fdset_2
		        // which cause problem in the next function. (This
happen when no concurrent clients increases the above said limit.
		       // This can be easily reproduced by reducing the
FD_SETSIZE to lets say 32. Now if the 33 client tries to connect while
remaing 32 are still in the call.
		       // then FD_SET fails and pd_n_fdset_2 is incremented.
      FD_SET(sock,&pd_fdset_2);
    }
...
...
}

Now lets see where the problem actually occurs:

/////////////////////////////////////////////////////////////////////////
CORBA::Boolean
SocketCollection::Select() {

...
...
  if (timeout.tv_sec == 0 && timeout.tv_usec == 0) {

    omni_thread::get_time(&pd_abs_sec,&pd_abs_nsec,
			  scan_interval_sec,scan_interval_nsec);
    timeout.tv_sec  = scan_interval_sec;
    timeout.tv_usec = scan_interval_nsec / 1000;

    omni_tracedmutex_lock sync(pd_fdset_lock);
    rfds  = pd_fdset_2;
    
    // I have changed the following statement from "total = pd_n_fdset_2;"
to "total = rfds.fd_count;" 
    // the reason of doing this is because the value of total would one more
then the required and 
    // while loop at bottom would become a infinite loop and thread hangs as
total will not decrement to ZERO!!! And using rfds.fd_count would
    // always give the right size.
	
    total = rfds.fd_count;// total = pd_n_fdset_2;
    pd_fdset_2 = pd_fdset_1;
    pd_n_fdset_2 = pd_n_fdset_1;
  }
  else {
    omni_tracedmutex_lock sync(pd_fdset_lock);
    rfds  = pd_fdset_2;
    
    //Same reason as the previous one
    total = rfds.fd_count;// total = pd_n_fdset_2;
  }

  int maxfd = 0;
  int fd = 0;
  while (total) {
    if (FD_ISSET(fd,&rfds)) {
      maxfd = fd;
      total--;
    }
    fd++;
  }
...
..
}



-----Original Message-----
From: Kamaldeep Singh Khanuja [mailto:Kkhanuja at quark.co.in] 
Sent: Tuesday, November 18, 2003 4:06 PM
To: omniorb-list at omniorb-support.com
Subject: [omniORB] RE: Major concurrency issue on Windows (OmniORB 4.0.1)

Hi Duncan,

My following posting remained unanswered.

Regards,
--Kamal

-----Original Message-----
From: Kamaldeep Singh Khanuja
Sent: Thursday, September 11, 2003 11:01 AM
To: 'omniorb-list at omniorb-support.com'
Subject: Major concurrency issue on Windows (OmniORB 4.0.1)


Hi Duncan,
Our application is a server application (uses OmniORB 4.0.1) where large
number of clients (usually greater than 300) connect to our server. On the
Windows version of this server, we have noticed that if there are more than
64 concurrent IDL (i.e. 64 socket connections opened with server) calls
pending on the server, the 65th IDL call from any other client application
blocks and the server stops responding there after. Upon investigating we
found that it is due to the limit specified in winsock2.h by using the
preprocessor macro FD_SETSIZE. By default it is 64, so I introduced the
following before winsock2.h is included in the OmniORB code:

// Should be moved to some Common place
// This is to support the Winsock implementation to support non-default
number of 
// open sockets for an application. [Default limit is 64] #undef FD_SETSIZE
#define FD_SETSIZE 2048

The above was done at two places:
1) src\lib\omniORB\orbcore\tcp\tcpTransportImpl.cc
2) include\omniORB4\internal\libcWrapper.h

After this I compiled the ORB and it worked fine for us!!!

I think it would make sense to include this change for Windows in the ORB
distribution. This could remain hard-coded to 2048 or be made configurable
using a makefile macro.

Best Regards,
--Kamal

_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list