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