commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Sun, 17 Oct 2010 15:49:29 GMT
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.

>
> Moreover is there some ideas of what kind of implementation will be used to
> implement the pool v2 ?

Current thinking is to integrate the code from the Tomcat jdbc-pool 
module.
>
> ArrayBlockingQueue is IMO a good candidate, and it even has a "fair"
> behavior that jdbc-pool try to reimplement on its own.

We should talk about why the Tomcat devs decided to implement their 
own FairBlockingQueue.

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.

Phil
>
> Kind regards,
>
> Benoit.
>
>
>
> 2010/10/13 Simone Tripodi<simone.tripodi@gmail.com>
>
>> Hi guys,
>> I'd add that not all properties are configurable, we should add
>> setters only in case it makes sense, or not?
>> All the best,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz<phil.steitz@gmail.com>
>> wrote:
>>>
>>>
>>>
>>>
>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible<joerg.schaible@gmx.de>
>> wrote:
>>>
>>>> Gary Gregory wrote:
>>>>
>>>>> I too would like to be able to tweak the size of the pool at runtime.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Oct 12, 2010, at 13:19, "James Carman"<james@carmanconsulting.com>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>>>>> <simone.tripodi@gmail.com>  wrote:
>>>>>>> Hi Phil! :)
>>>>>>> honestly I didn't understand which are the use cases when a pool
>> needs
>>>>>>> to be reconfigured, that's why I've always used the pool in
>> "configure
>>>>>>> and use" modality and Seb's suggestion sounded good to me. OTOH
I
>>>>>>> didn't modify any single code line before hearing your thoughts
since
>>>>>>> you know much more than me.
>>>>>>> If pool's property are mutable, so I need to add the setters,
make
>>>>>>> them final otherwise :P
>>>>>>
>>>>>> What if you want to alter the way the pool works at runtime?  Perhaps
>>>>>> you're seeing that it keeps causing long waits because you're not
>>>>>> allowing it to grow big enough?
>>>>
>>>> Why then not create a new pool and take over ownership of the objects?
>>>>
>>> There may be instances out in circulation.  Also requests waiting,
>> maintenance in progress, etc not to mention the need to redirect clients.
>>   The flexibility to be able to increase pool size or change other parameters
>> on the fly is good IMO and where we can safely support it without
>> performance impact we should.
>>>> - Jörg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>


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


Mime
View raw message