You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Tripodi <si...@gmail.com> on 2010/10/12 11:20:48 UTC
[pool] runtime re-configuration
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,
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
Re: [pool] Java 5 enhance for loop
Posted by Simone Tripodi <si...@gmail.com>.
cool, I read the commit and agree!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 7:16 PM, Gary Gregory
<GG...@seagullsoftware.com> wrote:
> I see that Java 5 enhance for loop are in used yet. I thought I'd fix that up. In progress...
>
> Gary
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[pool] Java 5 enhance for loop
Posted by Gary Gregory <GG...@seagullsoftware.com>.
I see that Java 5 enhance for loop are in used yet. I thought I'd fix that up. In progress...
Gary
Re: [pool] runtime re-configuration
Posted by Phil Steitz <ph...@gmail.com>.
Yes
On Oct 12, 2010, at 12:17 PM, Simone Tripodi <si...@gmail.com> wrote:
> Hi Phil,
> OK that's clear, according to this policy, just to keep things
> consistent, also *.Config properties should be accessed only by
> getters/setters, how does it sound for you?
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Oct 12, 2010 at 6:13 PM, Phil Steitz <ph...@gmail.com> wrote:
>> On 10/12/10 11:26 AM, sebb wrote:
>>>
>>> On 12 October 2010 16:03, Phil Steitz<ph...@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<se...@gmail.com> wrote:
>>>>>>
>>>>>> On 12 October 2010 10:20, Simone Tripodi<si...@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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [pool] runtime re-configuration
Posted by Simone Tripodi <si...@gmail.com>.
Hi Phil,
OK that's clear, according to this policy, just to keep things
consistent, also *.Config properties should be accessed only by
getters/setters, how does it sound for you?
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 6:13 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 10/12/10 11:26 AM, sebb wrote:
>>
>> On 12 October 2010 16:03, Phil Steitz<ph...@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<se...@gmail.com> wrote:
>>>>>
>>>>> On 12 October 2010 10:20, Simone Tripodi<si...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] runtime re-configuration
Posted by Simone Tripodi <si...@gmail.com>.
+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
<GG...@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 <ph...@gmail.com> wrote:
>> > On 10/12/10 11:26 AM, sebb wrote:
>> >>
>> >> On 12 October 2010 16:03, Phil Steitz<ph...@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<se...@gmail.com> wrote:
>> >>>>>
>> >>>>> On 12 October 2010 10:20, Simone Tripodi<si...@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
RE: [pool] runtime re-configuration
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----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 <ph...@gmail.com> wrote:
> > On 10/12/10 11:26 AM, sebb wrote:
> >>
> >> On 12 October 2010 16:03, Phil Steitz<ph...@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<se...@gmail.com> wrote:
> >>>>>
> >>>>> On 12 October 2010 10:20, Simone Tripodi<si...@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
Re: [pool] runtime re-configuration
Posted by sebb <se...@gmail.com>.
On 12 October 2010 17:13, Phil Steitz <ph...@gmail.com> wrote:
> On 10/12/10 11:26 AM, sebb wrote:
>>
>> On 12 October 2010 16:03, Phil Steitz<ph...@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<se...@gmail.com> wrote:
>>>>>
>>>>> On 12 October 2010 10:20, Simone Tripodi<si...@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
Re: [pool] runtime re-configuration
Posted by Phil Steitz <ph...@gmail.com>.
On 10/12/10 11:26 AM, sebb wrote:
> On 12 October 2010 16:03, Phil Steitz<ph...@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<se...@gmail.com> wrote:
>>>>
>>>> On 12 October 2010 10:20, Simone Tripodi<si...@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
Re: [pool] runtime re-configuration
Posted by sebb <se...@gmail.com>.
On 12 October 2010 16:03, Phil Steitz <ph...@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<se...@gmail.com> wrote:
>>>
>>> On 12 October 2010 10:20, Simone Tripodi<si...@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 ...
> 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
Re: [pool] runtime re-configuration
Posted by Simone Tripodi <si...@gmail.com>.
Good point James, thanks for the feedback! I suppose that's the reason
why previous maintainers let the fields protected to access them
directly, that will be replaced by setters/getters methods.
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 10:18 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> <si...@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?
>
> ---------------------------------------------------------------------
> 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
Re: [pool] runtime re-configuration
Posted by Simone Tripodi <si...@gmail.com>.
Well done Steven,
I'll take a look at the patch this evening (my timezone in GMT+2) if
someone else is not faster than me :)
Thanks,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 19, 2010 at 1:22 PM, Steven Siebert <sm...@gmail.com> wrote:
> Sounds like there is a fair amount of interest in the MBean approach.
>
> I created a JIRA ticket on this enhancement
> (#POOL-172<https://issues.apache.org/jira/browse/POOL-172>).
> I believe there are some similarities between this and
> #POOL-159<https://issues.apache.org/jira/browse/POOL-159>and
> #POOL-98 <https://issues.apache.org/jira/browse/POOL-98>, and these could
> possibly be satisfied by this work as well. Thoughts?
>
> As Simo suggested, I'll take a look at the jdbc-pool JMX support, the two
> aforementioned tickets, and the details in this thread and propose an
> interface back to this thread and related ticket for discussion prior to
> implementation.
>
> Since this can be done so that it does not affect the API, is there a
> need/desire to backport this?
>
> Regards,
>
> Steve
>
>
> On Tue, Oct 19, 2010 at 6:51 AM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 10/19/10 1:45 AM, Simone Tripodi wrote:
>>
>>> +1, I like the idea of using MBeans too!
>>>
>>
>> +1 - the Tomcat jdbc-pool code has the beginnings of this.
>>
>> Phil
>>
>>
>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Oct 18, 2010 at 11:05 PM, Matt Benson<gu...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote:
>>>>
>>>> -----Original Message-----
>>>>>> From: Steven Siebert [mailto:smsiebe@gmail.com]
>>>>>> Sent: Monday, October 18, 2010 04:52
>>>>>> To: Commons Developers List
>>>>>> Subject: Re: [pool] runtime re-configuration
>>>>>>
>>>>>> Why not add an (or a small set of) MBean(s) to where you can not only
>>>>>> manage
>>>>>> some of the mutable values, but also add the capability to runtime
>>>>>> monitor
>>>>>> the pool through jconsole and 3rd party JMX/network monitoring systems?
>>>>>> This would keep the pool API the same, reducing the need for you to
>>>>>> maintain
>>>>>> these in later versions. IMHO you would be gaining a lot more from
>>>>>> this
>>>>>> approach.
>>>>>>
>>>>>> If desired, I will volunteer to write the patch for this. I am using
>>>>>> this
>>>>>> approach to monitor my pools, adding accessors for configuration values
>>>>>> is
>>>>>> fairly trivial.
>>>>>>
>>>>>
>>>>> I do like this idea!
>>>>>
>>>>
>>>> +1
>>>>
>>>> -Matt
>>>>
>>>> Gary
>>>>>
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On Wed, Oct 13, 2010 at 6:29 AM, Simone Tripodi
>>>>>> <si...@gmail.com>wrote:
>>>>>>
>>>>>> 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://people.apache.org/%7Esimonetripodi/>
>>>>>> <http://people.apache.org/%7Esimonetri
>>>>>> podi/>
>>>>>>
>>>>>>> http://www.99soft.org/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz<ph...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible<jo...@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
>>>>>>>>>>> <si...@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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: [pool] runtime re-configuration
Posted by Steven Siebert <sm...@gmail.com>.
Sounds like there is a fair amount of interest in the MBean approach.
I created a JIRA ticket on this enhancement
(#POOL-172<https://issues.apache.org/jira/browse/POOL-172>).
I believe there are some similarities between this and
#POOL-159<https://issues.apache.org/jira/browse/POOL-159>and
#POOL-98 <https://issues.apache.org/jira/browse/POOL-98>, and these could
possibly be satisfied by this work as well. Thoughts?
As Simo suggested, I'll take a look at the jdbc-pool JMX support, the two
aforementioned tickets, and the details in this thread and propose an
interface back to this thread and related ticket for discussion prior to
implementation.
Since this can be done so that it does not affect the API, is there a
need/desire to backport this?
Regards,
Steve
On Tue, Oct 19, 2010 at 6:51 AM, Phil Steitz <ph...@gmail.com> wrote:
> On 10/19/10 1:45 AM, Simone Tripodi wrote:
>
>> +1, I like the idea of using MBeans too!
>>
>
> +1 - the Tomcat jdbc-pool code has the beginnings of this.
>
> Phil
>
>
> Simo
>>
>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Oct 18, 2010 at 11:05 PM, Matt Benson<gu...@gmail.com>
>> wrote:
>>
>>>
>>> On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote:
>>>
>>> -----Original Message-----
>>>>> From: Steven Siebert [mailto:smsiebe@gmail.com]
>>>>> Sent: Monday, October 18, 2010 04:52
>>>>> To: Commons Developers List
>>>>> Subject: Re: [pool] runtime re-configuration
>>>>>
>>>>> Why not add an (or a small set of) MBean(s) to where you can not only
>>>>> manage
>>>>> some of the mutable values, but also add the capability to runtime
>>>>> monitor
>>>>> the pool through jconsole and 3rd party JMX/network monitoring systems?
>>>>> This would keep the pool API the same, reducing the need for you to
>>>>> maintain
>>>>> these in later versions. IMHO you would be gaining a lot more from
>>>>> this
>>>>> approach.
>>>>>
>>>>> If desired, I will volunteer to write the patch for this. I am using
>>>>> this
>>>>> approach to monitor my pools, adding accessors for configuration values
>>>>> is
>>>>> fairly trivial.
>>>>>
>>>>
>>>> I do like this idea!
>>>>
>>>
>>> +1
>>>
>>> -Matt
>>>
>>> Gary
>>>>
>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>>> On Wed, Oct 13, 2010 at 6:29 AM, Simone Tripodi
>>>>> <si...@gmail.com>wrote:
>>>>>
>>>>> 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://people.apache.org/%7Esimonetripodi/>
>>>>> <http://people.apache.org/%7Esimonetri
>>>>> podi/>
>>>>>
>>>>>> http://www.99soft.org/
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz<ph...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible<jo...@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
>>>>>>>>>> <si...@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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
Re: [pool] runtime re-configuration
Posted by Phil Steitz <ph...@gmail.com>.
On 10/19/10 1:45 AM, Simone Tripodi wrote:
> +1, I like the idea of using MBeans too!
+1 - the Tomcat jdbc-pool code has the beginnings of this.
Phil
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Oct 18, 2010 at 11:05 PM, Matt Benson<gu...@gmail.com> wrote:
>>
>> On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote:
>>
>>>> -----Original Message-----
>>>> From: Steven Siebert [mailto:smsiebe@gmail.com]
>>>> Sent: Monday, October 18, 2010 04:52
>>>> To: Commons Developers List
>>>> Subject: Re: [pool] runtime re-configuration
>>>>
>>>> Why not add an (or a small set of) MBean(s) to where you can not only manage
>>>> some of the mutable values, but also add the capability to runtime monitor
>>>> the pool through jconsole and 3rd party JMX/network monitoring systems?
>>>> This would keep the pool API the same, reducing the need for you to maintain
>>>> these in later versions. IMHO you would be gaining a lot more from this
>>>> approach.
>>>>
>>>> If desired, I will volunteer to write the patch for this. I am using this
>>>> approach to monitor my pools, adding accessors for configuration values is
>>>> fairly trivial.
>>>
>>> I do like this idea!
>>
>> +1
>>
>> -Matt
>>
>>> Gary
>>>
>>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>> On Wed, Oct 13, 2010 at 6:29 AM, Simone Tripodi
>>>> <si...@gmail.com>wrote:
>>>>
>>>>> 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://people.apache.org/%7Esimonetri
>>>> podi/>
>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz<ph...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible<jo...@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"<ja...@carmanconsulting.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>>>>>>>> <si...@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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [pool] runtime re-configuration
Posted by Simone Tripodi <si...@gmail.com>.
+1, I like the idea of using MBeans too!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Oct 18, 2010 at 11:05 PM, Matt Benson <gu...@gmail.com> wrote:
>
> On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote:
>
>>> -----Original Message-----
>>> From: Steven Siebert [mailto:smsiebe@gmail.com]
>>> Sent: Monday, October 18, 2010 04:52
>>> To: Commons Developers List
>>> Subject: Re: [pool] runtime re-configuration
>>>
>>> Why not add an (or a small set of) MBean(s) to where you can not only manage
>>> some of the mutable values, but also add the capability to runtime monitor
>>> the pool through jconsole and 3rd party JMX/network monitoring systems?
>>> This would keep the pool API the same, reducing the need for you to maintain
>>> these in later versions. IMHO you would be gaining a lot more from this
>>> approach.
>>>
>>> If desired, I will volunteer to write the patch for this. I am using this
>>> approach to monitor my pools, adding accessors for configuration values is
>>> fairly trivial.
>>
>> I do like this idea!
>
> +1
>
> -Matt
>
>> Gary
>>
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> On Wed, Oct 13, 2010 at 6:29 AM, Simone Tripodi
>>> <si...@gmail.com>wrote:
>>>
>>>> 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://people.apache.org/%7Esimonetri
>>> podi/>
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz <ph...@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible <jo...@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" <ja...@carmanconsulting.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>>>>>>> <si...@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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [pool] runtime re-configuration
Posted by Matt Benson <gu...@gmail.com>.
On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote:
>> -----Original Message-----
>> From: Steven Siebert [mailto:smsiebe@gmail.com]
>> Sent: Monday, October 18, 2010 04:52
>> To: Commons Developers List
>> Subject: Re: [pool] runtime re-configuration
>>
>> Why not add an (or a small set of) MBean(s) to where you can not only manage
>> some of the mutable values, but also add the capability to runtime monitor
>> the pool through jconsole and 3rd party JMX/network monitoring systems?
>> This would keep the pool API the same, reducing the need for you to maintain
>> these in later versions. IMHO you would be gaining a lot more from this
>> approach.
>>
>> If desired, I will volunteer to write the patch for this. I am using this
>> approach to monitor my pools, adding accessors for configuration values is
>> fairly trivial.
>
> I do like this idea!
+1
-Matt
> Gary
>
>>
>> Regards,
>>
>> Steve
>>
>> On Wed, Oct 13, 2010 at 6:29 AM, Simone Tripodi
>> <si...@gmail.com>wrote:
>>
>>> 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://people.apache.org/%7Esimonetri
>> podi/>
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz <ph...@gmail.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible <jo...@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" <ja...@carmanconsulting.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>>>>>> <si...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [pool] runtime re-configuration
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Steven Siebert [mailto:smsiebe@gmail.com]
> Sent: Monday, October 18, 2010 04:52
> To: Commons Developers List
> Subject: Re: [pool] runtime re-configuration
>
> Why not add an (or a small set of) MBean(s) to where you can not only manage
> some of the mutable values, but also add the capability to runtime monitor
> the pool through jconsole and 3rd party JMX/network monitoring systems?
> This would keep the pool API the same, reducing the need for you to maintain
> these in later versions. IMHO you would be gaining a lot more from this
> approach.
>
> If desired, I will volunteer to write the patch for this. I am using this
> approach to monitor my pools, adding accessors for configuration values is
> fairly trivial.
I do like this idea!
Gary
>
> Regards,
>
> Steve
>
> On Wed, Oct 13, 2010 at 6:29 AM, Simone Tripodi
> <si...@gmail.com>wrote:
>
> > 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://people.apache.org/%7Esimonetri
> podi/>
> > http://www.99soft.org/
> >
> >
> >
> > On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz <ph...@gmail.com>
> > wrote:
> > >
> > >
> > >
> > >
> > > On Oct 12, 2010, at 4:42 PM, Jörg Schaible <jo...@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" <ja...@carmanconsulting.com>
> > >>> wrote:
> > >>>
> > >>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> > >>>> <si...@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
Re: [pool] runtime re-configuration
Posted by Steven Siebert <sm...@gmail.com>.
Why not add an (or a small set of) MBean(s) to where you can not only manage
some of the mutable values, but also add the capability to runtime monitor
the pool through jconsole and 3rd party JMX/network monitoring systems?
This would keep the pool API the same, reducing the need for you to maintain
these in later versions. IMHO you would be gaining a lot more from this
approach.
If desired, I will volunteer to write the patch for this. I am using this
approach to monitor my pools, adding accessors for configuration values is
fairly trivial.
Regards,
Steve
On Wed, Oct 13, 2010 at 6:29 AM, Simone Tripodi <si...@gmail.com>wrote:
> 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://people.apache.org/%7Esimonetripodi/>
> http://www.99soft.org/
>
>
>
> On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz <ph...@gmail.com>
> wrote:
> >
> >
> >
> >
> > On Oct 12, 2010, at 4:42 PM, Jörg Schaible <jo...@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" <ja...@carmanconsulting.com>
> >>> wrote:
> >>>
> >>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> >>>> <si...@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
>
>
Re: [pool] runtime re-configuration
Posted by Rainer Jung <ra...@kippdata.de>.
On 19.10.2010 00:56, Mark Thomas wrote:
> On 18/10/2010 01:22, Benoit Perroud wrote:
>> 2010/10/17 Phil Steitz<ph...@gmail.com>
>>> On 10/17/10 8:53 AM, Benoit Perroud wrote:
>>> We should talk about why the Tomcat devs decided to implement their own
>>> FairBlockingQueue.
>
> ENOCLUE. There might be something in the Javadoc but most likely not.
>
>> Good point for the fair queue. Is something from Tomcat reading this ML ?
>
> Some*one* is, yes.
Some*two* (at least), but even les clue about jdbc-pool.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] runtime re-configuration
Posted by Mark Thomas <ma...@apache.org>.
On 18/10/2010 01:22, Benoit Perroud wrote:
> 2010/10/17 Phil Steitz <ph...@gmail.com>
>
>> 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
> change.
>
> 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.
ENOCLUE. There might be something in the Javadoc but most likely not.
> Good point for the fair queue. Is something from Tomcat reading this ML ?
Some*one* is, yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] runtime re-configuration
Posted by Benoit Perroud <ki...@gmail.com>.
2010/10/17 Phil Steitz <ph...@gmail.com>
> 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
change.
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.
>
Re: [pool] runtime re-configuration
Posted by Phil Steitz <ph...@gmail.com>.
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<si...@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<ph...@gmail.com>
>> wrote:
>>>
>>>
>>>
>>>
>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible<jo...@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"<ja...@carmanconsulting.com>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>>>>> <si...@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
Re: [pool] runtime re-configuration
Posted by Benoit Perroud <ki...@gmail.com>.
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.
Moreover is there some ideas of what kind of implementation will be used to
implement the pool v2 ?
ArrayBlockingQueue is IMO a good candidate, and it even has a "fair"
behavior that jdbc-pool try to reimplement on its own.
Kind regards,
Benoit.
2010/10/13 Simone Tripodi <si...@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 <ph...@gmail.com>
> wrote:
> >
> >
> >
> >
> > On Oct 12, 2010, at 4:42 PM, Jörg Schaible <jo...@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" <ja...@carmanconsulting.com>
> >>> wrote:
> >>>
> >>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> >>>> <si...@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
>
>
Re: [pool] runtime re-configuration
Posted by Simone Tripodi <si...@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 <ph...@gmail.com> wrote:
>
>
>
>
> On Oct 12, 2010, at 4:42 PM, Jörg Schaible <jo...@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" <ja...@carmanconsulting.com>
>>> wrote:
>>>
>>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>>> <si...@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
Re: [pool] runtime re-configuration
Posted by Phil Steitz <ph...@gmail.com>.
On Oct 12, 2010, at 4:42 PM, Jörg Schaible <jo...@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" <ja...@carmanconsulting.com>
>> wrote:
>>
>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>> <si...@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
RE: [pool] runtime re-configuration
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Gary Gregory
> Sent: Tuesday, October 12, 2010 17:08
> To: dev@commons.apache.org; 'joerg.schaible@gmx.de'
> Subject: RE: [pool] runtime re-configuration
>
> > -----Original Message-----
> > From: Jörg Schaible [mailto:joerg.schaible@gmx.de]
> > Sent: Tuesday, October 12, 2010 16:42
> > To: dev@commons.apache.org
> > Subject: Re: [pool] runtime re-configuration
> >
> > 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" <ja...@carmanconsulting.com>
> > > wrote:
> > >
> > >> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> > >> <si...@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?
>
> It is easier to say: pool.setMaxActive(n);
>
> If changing these settings at runtime while enforcing proper semantics is a
> big deal, we should create an immutable class with a mutable subclass.
Or provide mutable and immutable interfaces.
Gary
>
> Gary
>
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
RE: [pool] runtime re-configuration
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Jörg Schaible [mailto:joerg.schaible@gmx.de]
> Sent: Tuesday, October 12, 2010 16:42
> To: dev@commons.apache.org
> Subject: Re: [pool] runtime re-configuration
>
> 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" <ja...@carmanconsulting.com>
> > wrote:
> >
> >> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> >> <si...@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?
It is easier to say: pool.setMaxActive(n);
If changing these settings at runtime while enforcing proper semantics is a big deal, we should create an immutable class with a mutable subclass.
Gary
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] runtime re-configuration
Posted by Jörg Schaible <jo...@gmx.de>.
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" <ja...@carmanconsulting.com>
> wrote:
>
>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>> <si...@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?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] runtime re-configuration
Posted by Gary Gregory <GG...@seagullsoftware.com>.
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" <ja...@carmanconsulting.com> wrote:
> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> <si...@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?
>
> ---------------------------------------------------------------------
> 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
Re: [pool] runtime re-configuration
Posted by James Carman <ja...@carmanconsulting.com>.
On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
<si...@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] runtime re-configuration
Posted by Simone Tripodi <si...@gmail.com>.
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
Just let me know!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 5:03 PM, Phil Steitz <ph...@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<se...@gmail.com> wrote:
>>>
>>> On 12 October 2010 10:20, Simone Tripodi<si...@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.
>
> 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
Re: [pool] runtime re-configuration
Posted by Phil Steitz <ph...@gmail.com>.
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<se...@gmail.com> wrote:
>> On 12 October 2010 10:20, Simone Tripodi<si...@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.
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
Re: [pool] runtime re-configuration
Posted by Simone Tripodi <si...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 12 October 2010 10:20, Simone Tripodi <si...@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?
>
>> 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
Re: [pool] runtime re-configuration
Posted by sebb <se...@gmail.com>.
On 12 October 2010 10:20, Simone Tripodi <si...@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?
> 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