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 <smsi...@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.ste...@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<gudnabr...@gmail.com> >>> wrote: >>> >>>> >>>> On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote: >>>> >>>> -----Original Message----- >>>>>> From: Steven Siebert [mailto:smsi...@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.trip...@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.ste...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible<joerg.schai...@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"< >>>>>>>>>> ja...@carmanconsulting.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi >>>>>>>>>>> <simone.trip...@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-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
