[omniORB] omniORB behaviour under load

Carlson, Andy andycarlson@ipo.att.com
Wed, 20 Oct 1999 04:31:12 -0700


Thanks for the answer...

>The only problem is how to keep track of the number of active
>To do so, you have to install a giopServerThreadWrapper (see omniORB.h for
>details). This wrapper is called whenever a Server thread is started. The
>argument passed to the wrapper is a tcpSocketStrand object. Using the
>handle() method of class tcpSocketStrand you can recover the socket.
>When the server thread exits, i.e. the socket is closed, you can decrement
>in your giopServerThreadWrapper the active connection count.

This is almost exactly what I am doing. The only difference is that I have
own implementation of tcpSocketWorker and GIOP_S etc. I have now looked
at the Gatekeeper stuff again and although I'm not using a Gatekeeper, the
effect of my code is the same, i.e. to shutdown the incoming socket early in

the run method of the worker thread when the total number of connections 
exceeds an internal limit. The snag is that the client seems to take this as
cue to reconnect and goes on doing so at a very high rate. This rejection 
approach (and Gatekeeper) creates a worker thread for each client connection

it rejects.

The current implementation hangs together most of the time if I set my
connection limits low enough to allow some margin before I hit the Solaris
limits. This allows several connections to be in the process of rejection
killing the remaining processing. The main problem is that when I run with
things often slow down enough to start hitting the file descriptor limits

I'm wondering is there is a way to reject the client connection before I
have created
a worker thread? - This would be less overhead on my application and might
persuade the client to stop retrying the connection.

>By the way, I guess you have already increase ulimit on the max. number of
>socket descriptors per unix process. I believe the default is just 64 on

That sounds about right. I've left it as is for now - I want to test what
happens at
or near the limit, so a low limit is useful for this purpose. I will
increase it when
I am finished trying to make it fail (or want it to fail in new ways!).

Andy Carlson. AT&T Labs (UK)   	Tel: +44 1527 495258
E-Mail: andycarlson@ipo.att.com	Fax: +44 1527 495229