commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Siebert <smsi...@gmail.com>
Subject Re: [pool] "Smart" (aka auto-configure) pools
Date Fri, 05 Nov 2010 17:01:44 GMT
xfer to dev distro =)


> On Nov 5, 2010, at 10:23 AM, James Carman <james@carmanconsulting.com>
> wrote:
>
> > On Fri, Nov 5, 2010 at 10:11 AM, Phil Steitz <phil.steitz@gmail.com>
> wrote:
> >>
> >> The challenge with making a smart pool implementation is that it is hard
> to
> >> define an algorithm that "does no harm" (i.e. always actually improves
> >> performance) can be fully documented and is at least tractable to
> document,
> >> maintain and support.  That does not mean it is impossible and I am
> >> interested in having a look at your ideas.
> >>
> >
> > Why not set it up so that the algorithm could be "plugged in" instead
> > of trying to come up with the end-all be-all solution?
>
> +1
>

Agreed!

>
> > The trick is
> > to make sure you capture all the metrics necessary for the plugged in
> > strategy can make its decision(s).  Or, you could do it another way.
> > You could allow the implementation to track all of the stuff that it
> > needs on its own.  This way, you'd have to "publish" events for
> > interested parties to subscribe to (object borrowed, object returned,
> > object discarded, etc.)
> >
> +1 but it would probably be more convenient for users to be able to
> hitchhike on the maintenance thread as Steve suggests to actually kick off
> adjustments.  Also, not just the pool but also object factories will need to
> publish events.
>
>
I think we might have a couple options for this...but since we're planning
JMX instrumentation, perhaps we can leverage this to provide
notifications/eventing back to the service.  This way, we're still letting
the maintenance thread do the work, it is just updating the MBean as it
normally would.  In this scenario, the "auto-manager" would use JMX to then
modify the runtime configuration though the same methods it would expose via
JMX.  Thoughts?


> We should probably take this discussion to the dev list at this point.
>
> Phil
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

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