commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Tue, 19 Oct 2010 10:51:03 GMT
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<gudnabrsam@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
>>>> <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
>>
>>
>
> ---------------------------------------------------------------------
> 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