commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Siebert <smsi...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Tue, 19 Oct 2010 11:22:29 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message