[omniORB] omniORB behaviour under load

[Carlson, Andy]

Hi omniORB-ers,

I've been doing some more testing using our omniORB-based
application under heavy load conditions. As it looks as if it will
be difficult to cover every possible resource starvation case I'm
now modifying the application so that it protects itself from such
situations. Here are some questions and observations (based on
omniORB 2.7.1 on Solaris)...

1. What is omniORB::maxTcpConnectionPerServer supposed to
    do? - I expected it to throttle incoming connections after a
    certain number, but for some reason it doesnt do this in my
    application. Does it only apply to Strands within a Rope?

2. I've now changed my app to count incoming connections and
    throttle them when they exceed a certain number. I'm doing this
    using tcpSocketMTincomingFactory::stopIncoming(). Is this
    what it's intended for or should I be doing it another way?

The stopIncoming approach works - sometimes! It always has the
desired effect but sometimes it seems to get in a mess because
startIncoming is unable to re-enable receipt of new connections
once the load has dropped to a manageable level.

It may be a coincidence but I usually get the 
"tcpSocketIncomingRope::cancelThreads() cannot create a socket..."
message at about the same time as I call startIncoming (yes - I
do mean startIncoming). It could be that the startIncoming call and
the message are causally related or it could be that both this error and
the dropping of active connections to a manageable level rely on timeouts
which begin and expire at almost the same time.

Once this error has occurred the incoming Rope gets into state 
SHUTDOWN and has no way to get into NO_THREAD state. 
As a result, startIncoming wont work.

Any Ideas?

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