tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Checkoway <dchecko...@gmail.com>
Subject Re: Executor thread lifecycle
Date Tue, 20 Sep 2011 20:26:17 GMT
If commons-pool supported bulk borrow/return in a single blocking operation,
I'd be all over it.  But the fact that if I want to borrow 3000 objects from
the pool, it's 3000 blocking ops, that's a non-starter.

Unless I'm missing something?  If there's a "minimally blocking" pool impl
that supports bulk borrow/return, shoot it my way...thx.

On Tue, Sep 20, 2011 at 3:11 PM, Mark Thomas <markt@apache.org> wrote:

> On 20/09/2011 20:06, Dan Checkoway wrote:
> > To be specific, we're having a major issue with garbage generation.  To
> > avoid this, we're pre-allocating pools of instances (up until now
> > ThreadLocal, but that's obviously changing).  When a request is processed
> it
> > may need anywhere between 1 and N objects from the pool, which it grabs
> and
> > uses, and then returns them to the pool when finished.  If N > pool size,
> > new instances get allocated on the fly, and they get added to the pool as
> > well.
> >
> > Sounds like a big memory leak in the making, right?  Yeah, except there's
> a
> > rational cap on the total # of instances each thread will ever need.  So
> > this ended up being dramatically more efficient because it generated
> > essentially zero garbage over time.  GC could keep up again...
> >
> > Until this proved to be its own garbage generator.  :-)  As threads got
> > recycled, the ThreadLocal pools got turned to garbage.  Foiled again!
>  :-)
> >
> > So yeah, I'm going to centralize the pool and just synchronize management
> of
> > it.  Oy.
>
> You might want to take a look at Commons Pool trunk. It has been
> completely re-written for 2.0 for performance. There is still some work
> to do before a release but the GenericObjectPool should be OK and
> performs well in a multi-threaded environment (the
> GenericKeyedObjectPool has a known bug I need to fix).
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

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