commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [pool] runtime re-configuration
Date Wed, 13 Oct 2010 00:07:45 GMT
> -----Original Message-----
> From: Jörg Schaible [mailto:joerg.schaible@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" <james@carmanconsulting.com>
> > wrote:
> >
> >> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> >> <simone.tripodi@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.

Gary

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

Mime
View raw message