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 Tue, 12 Oct 2010 16:13:06 GMT
On 10/12/10 11:26 AM, sebb wrote:
> On 12 October 2010 16:03, Phil Steitz<phil.steitz@gmail.com>  wrote:
>> On 10/12/10 7:32 AM, Simone Tripodi wrote:
>>>
>>> Hi Seb,
>>> I totally agree, I'm for this solution, BTW I'll wait the Phil's
>>> opinion that knows more than me.
>>> Thanks!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Tue, Oct 12, 2010 at 12:50 PM, sebb<sebbaz@gmail.com>    wrote:
>>>>
>>>> On 12 October 2010 10:20, Simone Tripodi<simone.tripodi@gmail.com>
>>>>   wrote:
>>>>>
>>>>> Hi all guys,
>>>>> while fixing the deprecated properties in classes like
>>>>> StackKeyedObjectPool[1], I noticed this class instance was
>>>>> re-configured during the test[2] (see line 126); is the
>>>>> "reconfigure-in-runtime" a pool feature we want? I'm asking because
>>>>> I've never experienced the pool reconfiguration (I've never had the
>>>>> need to do it) so I honestly don't know which is the wished behavior.
>>>>> In the scenario we want to keep this feature, since I'm converting
>>>>> fields as private, I need to add setters.
>>>>> Just let me know!!! Have a nice day,
>>>>
>>>> AFAIK, the tests that modify the configuration are to be dropped once
>>>> the variables are made private.
>>>> The idea was not just to make the variables private, but to make them
>>>> final as far as possible to improve thread safety.
>>>>
>>>> Perhaps Phil can confirm this?
>>
>> The only property that I think we have agreed at this point to make
>> immutable is the factory.  I am open to talking about making other
>> properties immutable, but I think we should get some broader input on this
>> topic.
>
> The field in question is _maxSleeping which has already been marked as:
>
> "@deprecated to be removed in pool 2.0.  Use {@link #getMaxSleeping()}"
>
> The field is settable by using the appropriate constructor.
>
> I thought we had decided to make such fields final as part of POOL-169?
>
> Indeed, it seems it was psteiz who committed r990437 which added the
> deprecated comment ...s

I meant to deprecate the protected field - meaning that direct 
access would not be supported in 2.0.  I did not mean to imply that 
the decision had been made that there would be no setter.  We need 
to talk about this general topic.  I have a few times had occasion 
to increase maxActive and make other modifications to pools at 
runtime.  I could personally live without this, but it is a big 
difference that we should allow the community to weigh in on if we 
are talking here about all pool properties.

Phil
>
>> Phil
>>>>
>>>>> Simo
>>>>>
>>>>> [1] http://s.apache.org/bjw
>>>>> [2] http://s.apache.org/qB
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://www.99soft.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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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