tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: [proposal] remove worker based connector thread pools in trunk
Date Fri, 14 Aug 2009 17:09:26 GMT
On 08/14/2009 10:48 AM, Costin Manolache wrote:
> +1 - Executor seems the right interface, didn't exist when workers were
> started - ifanyone needs the pool behavior it can probably be implemented as
> an Executor.
>
> I assume you'll have some way to configure what kind of executor ?
>    

Yes we do, the NIO connector doesn't use workers anymore. It can use an 
internal executor, or an external one. Both are configurable through 
server.xml, and the config will not change at all. If you take a 6.0 
config, it would still work.
Furthermore, there is some really cool stuff we can do with executors, 
such as even with the BIO connector, we can do keep alives and and still 
rotate the sockets among the available threads.


> Costin
>
> On Fri, Aug 14, 2009 at 1:30 AM, Mark Thomas<markt@apache.org>  wrote:
>
>    
>> Filip Hanik - Dev Lists wrote:
>>      
>>> Here is why I think its good
>>>
>>> 1. Current pools can't shrink, so when peak has been hit, that's where
>>> were at
>>> 2. Current pools are unfair, synchronized (workers) { workers.wait() },
>>> executors are a bit more fair since they only hold a lock for a short
>>> period
>>> 3. Reduce duplicate code
>>> 4. Executors provide more flexibility
>>> 5. I have not found a performance difference anymore
>>> 6. Async implementation becomes much easier, since
>>> AsyncContext.dispatch() is easily handed off to an executor and
>>> releasing application thread. Otherwise we have to add an executor on
>>> top of the existing thread pool, which is doable, just not pragmatic
>>>        
>> If you mean give each connector it's own executor by default and the
>> option to use a shared executor then +1
>>
>> For the record, it was point 6 that made the argument for me.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>      
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message