commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Mon, 18 Oct 2010 21:05:11 GMT

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
>> <simone.tripodi@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 <phil.steitz@gmail.com>
>>> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible <joerg.schaible@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
>>>>>>> <simone.tripodi@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


Mime
View raw message