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 12:24:35 GMT
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 <smsiebe@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 <phil.steitz@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<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/%7Esimonetripodi/>
>>>>>> <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
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message