commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Perroud <>
Subject Re: [pool] runtime re-configuration
Date Mon, 18 Oct 2010 06:22:45 GMT
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

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.

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

As a side note, as of 1.5, the now "legacy" [pool] code implements fairness.
>  The Tomcat code is configurable - i.e., can behave fairly or not.  I have
> just started analyzing the performance tests included in jdbc-pool, but they
> appear to indicate that, as expected, fairness dampens mean response but
> decreases variance.  I like the approach of making fairness configurable.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message