commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Tue, 12 Oct 2010 16:49:55 GMT
+1 also on syncronizing the methods, I can take this task in charge.
Thanks all,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Oct 12, 2010 at 6:46 PM, Gary Gregory
<GGregory@seagullsoftware.com> wrote:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Tuesday, October 12, 2010 09:39
>> To: Commons Developers List
>> Subject: Re: [pool] runtime re-configuration
>>
>> 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.
>
> +1 too 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
>
>
> ---------------------------------------------------------------------
> 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