commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [pool] runtime re-configuration
Date Mon, 18 Oct 2010 22:56:33 GMT
On 18/10/2010 01:22, Benoit Perroud wrote:
> 2010/10/17 Phil Steitz <phil.steitz@gmail.com>
> 
>> On 10/17/10 8:53 AM, Benoit Perroud wrote:
>>
>>> Making pool be able to be resized at runtime will introduce extra
>>> complexity, that could be otherwise totally delegated to a BlockingQueue
>>> as
>>> backend structure.
>>>
>>
>> I don't understand exactly what you are saying here.  The question is
>> should the user-exposed properties governing the size, max number of idle
>> elements, etc. be mutable at runtime.  Regardless of the choice of data
>> structure to maintain the pool, deciding this in the negative puts some
>> serious constraints on user code.
>>
>>
> I mean, if we decide to use a BlockingQueue as backend and allow users to
> resize the queue, then we will need to reinstanciate the queue at every size
> change.
> 
> In jdbc-pool at least, in case of unfair queue, they use a
> ArrayBlockingQueue, and thus the queue size is not resizable on the fly.
> 
> 
>> We should talk about why the Tomcat devs decided to implement their own
>> FairBlockingQueue.

ENOCLUE. There might be something in the Javadoc but most likely not.

> Good point for the fair queue. Is something from Tomcat reading this ML ?

Some*one* is, yes.




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


Mime
View raw message