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 <ma...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
