commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "otisg" <>
Subject Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Date Sat, 27 Apr 2002 21:04:49 GMT
So after the recent discussion I think the conclusion would be as
- Look at Avalon/Excalibur pool implementation and the inspection code
- Note any flaws, learn from mistakes made in that code
- Implement what you proposed below and try to make it better than
Excalibur impl.

Sign up for FREE iVillage newsletters <> .
>From health and pregnancy to shopping and sex, iVillage
has the scoop on what matters most to you. 

<-----Original Message----->
> From: Steven Caswell
> Sent: 4/23/2002 8:26:39 PM
> To:
> Subject: [pool] PROPOSAL: add collecting of statistics to pool
> Proposal: add collecting of statistics to pool implementations
> Reasoning: I'd like to be able to get stats from a pooling
> implementation to see how well the various configuration parameters
> set. For example, in the GenericObjectPool implementation, I'd like to
> know how many waits occurred, how many times the pool was extended,
> Proposed design changes:
> - Create an interface called PoolStatistics that defines operations
> obtaining the statistics values and associated labels. Actual values
> would be returned in an array of ints. Value labels would be returned
> an array of Strings. This would allow each pool implementation class
> define its own set of statistics and label them accordingly.
> - Create an interface called Measurable that would be implemented by a
> pool that supports reporting of statistics. This interface defines the
> operation that returns an instance of PoolStatistics. Defining a
> separate interface allows individual pool implementations to support
> not support reporting statistics at the choosing of the implementor.
> I've attached source code for the new PoolStatistics and Measurable
> interfaces. I've also attached patches to the GenericObjectPool and
> GenericObjectPoolFactory implementation classes that provide a first
> implementation, and the TestGenericObjectPool test case. I've run the
> test cases on these changes and they pass. If this proposal is
> in some form I'll be happy to add a first cut implementation to the
> other pool implementation classes.
> Steven Caswell

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