commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
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 <>
>> 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:
For additional commands, e-mail:

View raw message