hi sandy i had intended to sit down and analyse the code in detail. however, i have given it a quick once over and it looks very interesting. i'm happy with the general direction of the code. i work best when i can create patches for small issues as i go. this is difficult when the code isn't in a code repository, so i think it's best to try to get the paperwork started as quickly as possible (since it may take a while to get everything sorted out).
i'm sure you're aware of all these issues but it's important to the ASF that our code base is clean legally. so, before we can accept such any substantial contribution we need some legal paperwork from you. unfortunately, the ASF is still growing the process (through the incubator project) so i need to find out (and then document) what's required (in specific terms). this may take me a few days. in general terms, the code base needs to be clean and original with a known provenance. we also need you to either fax or post some signed legal documents to the ASF. are either of these requirements likely to be an issue? - robert On Thu, 2005-11-10 at 17:29 -0500, Sandy McArthur wrote: > Any other feedback? See: http://sandy.mcarthur.org/pool/ > > Since I've sent the last email I've reworked the idle object evictor > code such that it generates the least amount of contention I think is > possible short of using util.concurrent locking. The new eviction code > has the following properties: > > * Synchronization on a object pool is only for the duration it takes > to evict one idle object at a time. Previously the evictor thread had > exclusive access to object pool while it was working the list of idle > objects. While this will use more CPU to acquire and release more > synchronization locks the object pool as a whole will be much more > responsive. That increased time acquiring locks should also be negated > as the eviction code is simpler and no longer does redundant work > re-traversing lists of idle objects searching for one to evict. > > * The evictor no longer polls the list of idle objects for possible > evictions but a TimerTask is created for each idle object. This means > that if you want an idle object to be evicted after 10 minutes, it > will be evicted at the first opportunity the evictor can synchronize > on the pool after 10 minutes has passed. No longer is eviction a fuzzy > value between the requested 10 minutes and possible next eviction run > at 19 minutes and 59 seconds. While still not perfectly deterministic, > it much more deterministic and that is a Good Thing (TM). > > Again, feedback is welcomed: http://sandy.mcarthur.org/pool/ > > On 11/9/05, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > In the past weeks I've been working on a new implementation for Pool > > that I'm calling a Composite Object Pool (COP). I'm at the point where > > I think I've implemented everything I think the pool should have and > > then some. I would like feedback on the code and if the response is > > favorable I'll submit it for addition to the pool project. > > > > Generated JavaDocs and source code can be found at: > > http://sandy.mcarthur.org/pool/ > > > > Below is a list of things going for this code: > > > > * Implements almost all existing features in the current > > implementations. I think the ability to specific a minIdle object > > count and to skip validation when borrowing objects are the only > > existing features not implemented. I think it's wrong to not implement > > the former and I'm not convinced the ladder is really a good thing. > > > > * Very consistent features/behavior across pool types. The feature set > > of GenericObjectPool (COP) is quite different than StackObjectPool > > (SOP). With COP the features available to a LIFO (SOP) are the same as > > the features available to a FIFO (GOP) > > > > * Only returns an activated and valid object or a newly created > > object. It seems silly to me to require clients of an ObjectPool to > > deal with checking and validating borrowed objects. > > > > * Pools are named by what they do, not how they are implemented. eg: > > LifoOP vs StackOP > > > > * Active objects that are not returned to the pool can be detected. > > Optionally, the stack at time of borrow for lost objects can be logged > > to aid in debugging. I think this feature is pretty cool. > > > > * Synchronization is maintained via a private lock idiom. > > > > * Keyed pools have fine grained locking when possible. > > > > * Very modular code. A pool's feature set is assembled with composition. > > > > * All CompositeObjectPools share the same java util Timer thread. > > > > * Idle object evictor turns itself off when the pool is empty to > > reduce useless work. > > > > * Idle object evictor will try to limit how long it keeps the pool > > tied up during evictions. This is similar to > > GOP.setNumTestsPerEvictionRun(int) but time based instead of object > > count based. > > > > * The pool factory minimally tries to optimize the the composed object > > pool based on parameter values. > > > > * Future proof. (soon to be famous last words?) None of the > > implementation is made visible and could be gutted and replaced > > without breaking 3rd party code. > > > > * Keyed pools can use a non-keyed PoolableObjectFactory too. > > > > * No decencies beyond the Java 1.4 JDK. It wouldn't be hard to make it > > Java 1.3 compatable. > > > > > > Things left to do are: > > > > * Fix any JavaDoc mistakes. > > > > * Implement more unit tests and fix any bugs that turn up. > > (denotations welcome.) > > > > * Current idle object evictor code behaves in a way similar to the > > GOP's evictor code. For this to be thread-safe all other access to the > > pool while evicting idle objects must be blocked and it is not very > > deterministic for when an idle object will actually be evicted. > > > > * Create/Run some benchmarks to verify the performance is good. > > > > * When Java 1.5 is considered a reasonable requirement the > > util.concurrent can probably be used to improve parallelization. > > > > -- > > Sandy McArthur > > -- > Sandy McArthur > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
