[ 
https://issues.apache.org/jira/browse/POOL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608474#action_12608474
 ] 

Bryce Alcock commented on POOL-98:
----------------------------------


Getting back to Phil's Question:

Other than the current counters numActive, numIdle, and the pool properties, 
what would be most useful for management?

I would like to see the following (Grouped in order of importance):

Total Objects borrowed:
Total Objects Returned:

Total Objects created:
Total Objects removed for any Reason:

Total Objects removed by eviction thread:
Total Objects removed by testOnBorrow:

Avg Borrow Time:
max Borrow Time:


Some further stats that might help but would be much more difficult to track 
would be:
Avg Lend Time.
Avg Idle Time.


I have given this some thought as to "Extending GenericObjectPool" to do this, 
but I don't want to because  It would be nice to use the "Once Stop Shop" of 
BaseConnectionPool from DBCP, which rely's on GenericObjectPool. 

In the above request the first 4 groups could be done with simple counters, and 
minimum synchronization, item 5 could be done with a timer and counter, and the 
Avg Lend Time, and Avg Idle Time are more difficult.



> Make GenericObjectPool better extensible
> ----------------------------------------
>
>                 Key: POOL-98
>                 URL: https://issues.apache.org/jira/browse/POOL-98
>             Project: Commons Pool
>          Issue Type: Improvement
>    Affects Versions: 1.3
>            Reporter: Henning Schmiedehausen
>            Priority: Minor
>             Fix For: 2.0
>
>
> The current implementation of GenericObjectPool encapsulates the _pool
> object and there is no way to get it directly, which makes some things
> like JMX pool monitoring a bit awkward.
> Would it be possible to either make _pool protected or add a method
> protected Collection getInternalPool() {
>         return _pool;
> }
> or something like that to the GenericObjectPool implementation (and
> probably others, but that is the one that bites me most... :-) )
> This would make extending the GenericObjectPool much easier.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to