commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Tue, 12 Oct 2010 16:39:23 GMT
On 12 October 2010 17:13, Phil Steitz <phil.steitz@gmail.com> wrote:
> 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.

I see.

At least once we have moved to private fields and getters/setters, the
methods can be made synchronised to provide thread-safe updates and
publication.
And of course it's much easier to add debugging to track changes.

+1 to no direct access to mutable fields.

> 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
>
>

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


Mime
View raw message