commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Tue, 19 Oct 2010 05:45:31 GMT
+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 <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


Mime
View raw message