[pool] runtime re-configuration

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[pool] runtime re-configuration

Simone Tripodi
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

sebb-2-2
On 12 October 2010 10:20, Simone Tripodi <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Simone Tripodi
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 <[hidden email]> wrote:

> On 12 October 2010 10:20, Simone Tripodi <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Phil Steitz
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<[hidden email]>  wrote:
>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>  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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Simone Tripodi
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 <[hidden email]> 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<[hidden email]>  wrote:
>>>
>>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>
>>>  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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

sebb-2-2
In reply to this post by Phil Steitz
On 12 October 2010 16:03, Phil Steitz <[hidden email]> 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<[hidden email]>  wrote:
>>>
>>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>
>>>  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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Phil Steitz
On 10/12/10 11:26 AM, sebb wrote:

> On 12 October 2010 16:03, Phil Steitz<[hidden email]>  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<[hidden email]>    wrote:
>>>>
>>>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>
>>>>   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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Simone Tripodi
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 <[hidden email]> wrote:

> On 10/12/10 11:26 AM, sebb wrote:
>>
>> On 12 October 2010 16:03, Phil Steitz<[hidden email]>  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<[hidden email]>    wrote:
>>>>>
>>>>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>
>>>>>  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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

sebb-2-2
In reply to this post by Phil Steitz
On 12 October 2010 17:13, Phil Steitz <[hidden email]> wrote:

> On 10/12/10 11:26 AM, sebb wrote:
>>
>> On 12 October 2010 16:03, Phil Steitz<[hidden email]>  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<[hidden email]>    wrote:
>>>>>
>>>>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>
>>>>>  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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [pool] runtime re-configuration

Gary Gregory
> -----Original Message-----
> From: sebb [mailto:[hidden email]]
> 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 <[hidden email]> wrote:
> > On 10/12/10 11:26 AM, sebb wrote:
> >>
> >> On 12 October 2010 16:03, Phil Steitz<[hidden email]>  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<[hidden email]>    wrote:
> >>>>>
> >>>>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>
> >>>>>  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: [hidden email]
> >>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Simone Tripodi
+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
<[hidden email]> wrote:

>> -----Original Message-----
>> From: sebb [mailto:[hidden email]]
>> 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 <[hidden email]> wrote:
>> > On 10/12/10 11:26 AM, sebb wrote:
>> >>
>> >> On 12 October 2010 16:03, Phil Steitz<[hidden email]>  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<[hidden email]>    wrote:
>> >>>>>
>> >>>>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>
>> >>>>>  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: [hidden email]
>> >>>>>> For additional commands, e-mail: [hidden email]
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: [hidden email]
>> >>>>> For additional commands, e-mail: [hidden email]
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: [hidden email]
>> >>>> For additional commands, e-mail: [hidden email]
>> >>>>
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[pool] Java 5 enhance for loop

Gary Gregory
In reply to this post by Simone Tripodi
I see that Java 5 enhance for loop are in used yet. I thought I'd fix that up. In progress...

Gary
Reply | Threaded
Open this post in threaded view
|

Re: [pool] Java 5 enhance for loop

Simone Tripodi
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
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Phil Steitz
In reply to this post by Simone Tripodi
Yes



On Oct 12, 2010, at 12:17 PM, Simone Tripodi <[hidden email]> 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 <[hidden email]> wrote:
>> On 10/12/10 11:26 AM, sebb wrote:
>>>
>>> On 12 October 2010 16:03, Phil Steitz<[hidden email]>  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<[hidden email]>    wrote:
>>>>>>
>>>>>> On 12 October 2010 10:20, Simone Tripodi<[hidden email]>
>>>>>>  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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

James Carman
In reply to this post by Simone Tripodi
On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Simone Tripodi
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
<[hidden email]> wrote:

> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Gary Gregory
In reply to this post by James Carman
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" <[hidden email]> wrote:

> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] runtime re-configuration

Jörg Schaible
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" <[hidden email]>
> wrote:
>
>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [pool] runtime re-configuration

Gary Gregory
> -----Original Message-----
> From: Jörg Schaible [mailto:[hidden email]]
> Sent: Tuesday, October 12, 2010 16:42
> To: [hidden email]
> 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" <[hidden email]>
> > wrote:
> >
> >> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> >> <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [pool] runtime re-configuration

Gary Gregory
In reply to this post by Jörg Schaible
> -----Original Message-----
> From: Gary Gregory
> Sent: Tuesday, October 12, 2010 17:08
> To: [hidden email]; '[hidden email]'
> Subject: RE: [pool] runtime re-configuration
>
> > -----Original Message-----
> > From: Jörg Schaible [mailto:[hidden email]]
> > Sent: Tuesday, October 12, 2010 16:42
> > To: [hidden email]
> > 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" <[hidden email]>
> > > wrote:
> > >
> > >> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> > >> <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]

12