commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Perroud <killerwh...@gmail.com>
Subject Re: [pool] runtime re-configuration
Date Sun, 17 Oct 2010 12:53:11 GMT
Making pool be able to be resized at runtime will introduce extra
complexity, that could be otherwise totally delegated to a BlockingQueue as
backend structure.

Moreover is there some ideas of what kind of implementation will be used to
implement the pool v2 ?

ArrayBlockingQueue is IMO a good candidate, and it even has a "fair"
behavior that jdbc-pool try to reimplement on its own.

Kind regards,

Benoit.



2010/10/13 Simone Tripodi <simone.tripodi@gmail.com>

> 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://www.99soft.org/
>
>
>
> On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz <phil.steitz@gmail.com>
> wrote:
> >
> >
> >
> >
> > On Oct 12, 2010, at 4:42 PM, Jörg Schaible <joerg.schaible@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" <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?
> >>
> > 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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message