> -----Original Message-----
> From: Gary Gregory
> Sent: Tuesday, October 12, 2010 17:08
> To: dev@commons.apache.org; 'joerg.schai...@gmx.de'
> Subject: RE: [pool] runtime re-configuration
> 
> > -----Original Message-----
> > From: Jörg Schaible [mailto:joerg.schai...@gmx.de]
> > Sent: Tuesday, October 12, 2010 16:42
> > To: dev@commons.apache.org
> > Subject: Re: [pool] runtime re-configuration
> >
> > 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?
> 
> It is easier to say: pool.setMaxActive(n);
> 
> If changing these settings at runtime while enforcing proper semantics is a
> big deal, we should create an immutable class with a mutable subclass.

Or provide mutable and immutable interfaces.

Gary

> 
> Gary
> 
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to