commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lee Breisacher <>
Subject [pool] GenericObjectPool subclass
Date Fri, 07 Mar 2003 18:10:36 GMT
I recently ran into a problem with commons-pool v1.0.1 which is fixed in the
latest CVS revisions. Good news. However, with 1.0.1 I have a subclass of
GenericObjectPool that directly accesses a couple instance fields (details
below) that no longer compiles because the latest CVS revision of
GenericObjectPool has changed all the instance fields to be private.  I'm
hoping someone here has a suggestion...

A little background first:  The objects that I'm keeping in a pool are quite
time-consuming to create. The application that the pool lives in expects the
pooled objects to be available "right away" (as much as possible), so we
have the notion of pre-creating several objects and putting them in the pool
during application startup. In fact, I invented the notion of a pool with a
"minimum idle count" - the pool always has at least "minIdle" objects in it.
When an object is borrowed, a background filler thread back-fills the pool
with new objects.

The way I did this (using commons-pool 1.0.1) is by subclassing
GenericObjectPool and doing some "clever" tricks involving direct access to
the _factory and _numActive fields (see code below). Now I see that in the
latest revisions those fields have been made private so my code no longer

So, I'm scratching my head trying to figure out a way to do this.  I've
tried this seemingly obvious approach:  When a pool is created, call
borrowObject() a few times to pre-create some objects, then immediately
returnObject() each of them.  This actually works for pre-filling the pool,
but doesn't work so well for keeping the pool filled after "real"
borrowObject()s have been done -- say we want the pool to always have 4
objects available (minIdle=4), so we put 4 in at the start. Now a couple
real borrows are done, so there's 2 left. Now we try to re-fill back up to 4
by doing borrowObject(), but alas that simply returns one of the remaining 2
objects instead of creating a new one. I think you see the problem.

Any suggestions would be most welcome. FWIW, here's the code that I have in
my GenericObjectPool subclass (that no longer compiles):

	protected void checkMinIdle() throws Exception {
		while( this.needsFilling() ) {
			// Create one, then immediately return it to the
			Object obj = _factory.makeObject();
			synchronized(this) {
				_numActive++;	// A little slimy - must do
this because returnObject decrements it.

Perhaps one of the "owners" of commons-pool could add a protected
getFactory() method and a protected incrementNumActive() method, or perhaps
provide a protected addObject(obj) method that does the same thing as
returnObject() but does not decrement _numActive?



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