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/%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
