+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 <[email protected]> wrote: > > On Oct 18, 2010, at 3:35 PM, Gary Gregory wrote: > >>> -----Original Message----- >>> From: Steven Siebert [mailto:[email protected]] >>> 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 >>> <[email protected]>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 <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Oct 12, 2010, at 4:42 PM, Jörg Schaible <[email protected]> >>>> 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" <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi >>>>>>>> <[email protected]> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
