[omniORB] omniORB behaviour under load

[Carlson, Andy]

Sai-Lai,

Thanks for the answer...

>The only problem is how to keep track of the number of active
connections...
>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
my
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
a 
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
internal
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
without
killing the remaining processing. The main problem is that when I run with
Purify,
things often slow down enough to start hitting the file descriptor limits
again.

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
even 
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
Sun.

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
----------------------------------------------------------------------------
-----------
Andy Carlson. AT&T Labs (UK)   	Tel: +44 1527 495258
E-Mail: andycarlson@ipo.att.com	Fax: +44 1527 495229