geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: CORBA eating threads
Date Fri, 03 Jun 2005 04:21:44 GMT
On Jun 2, 2005, at 9:43 AM, Dain Sundstrom wrote:

>> How do we set it up so that if the pool is undersized then we get  
>> an error rather than just have the transport hang?
>>
>
> I'm looking into this one.  The default for the current thread pool  
> is to have the requesting thread run the task, which bad for our  
> case since the requesting thread is the socket acceptor.  I think  
> we should instead set abortWhenBlocked on the thread pool so we get  
> an exception.  It would be nice if there were a wait 10sec option  
> to deal with floods, but I don't see any options for that.

The problem was in the ThreadPool class we were using a work queue in  
addition to the thread pooling, so when we ran out of threads the  
work was just queued forever.  Normally a small fixed size buffer is  
desireable, since it can even out connection bursts, but since we had  
a total of one threads available any code that needs two threads to  
work (like a test using a timer) would lock up.  For now I have  
turned off the work queue and set the pool to throw an exception if a  
thread can not be immediately acquired.  This will help us drive out  
other bugs in the system.  Of course later on when tuning the server,  
the thread pool will be an obvious place to start.

-dain

Mime
View raw message