[
https://issues.apache.org/jira/browse/POOL-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17743558#comment-17743558
]
Phil Steitz commented on POOL-410:
----------------------------------
Moving a comment from PR to here. I think I now understand at least the stats
/ reporting ask here. We currently provide stats caching and reporting for
timing metrics. I think it is reasonable to ask for that for active and idle
counts. I would be happy to review a PR to add activeCounts and idleCounts to
go along with activeTimes and the other latency StatsStore instances now in
BaseGenericObjectPool. I would approach that by creating activeCounts and
idleCounts as StatsStore instances in BGOP and updating them in
updateStatsOnReturn and updateStatsOnBorrow, using current active and idle
counts from the pool. Then include these stats in reports. And tests. It is
maybe a slippery slope to add more and more stats caching and It might actually
be better to move in 3.0 to stats logging or listeners, but I think idle/active
counts are important enough to be added to what is currently being cached.
Another thing that is missing is control over the cache window / resetting the
caches. For the OPs use case, some way to set the cache size or time to live
would be needed. As of 2.11 it is hard-coded to the 100 most recent
measurements. Adding cache size confguration and a method to clear the cache
would be helpful here.
> EHN Max Concurrent Connections in Stats
> ---------------------------------------
>
> Key: POOL-410
> URL: https://issues.apache.org/jira/browse/POOL-410
> Project: Commons Pool
> Issue Type: Improvement
> Reporter: Thomas Freller
> Priority: Major
>
> For tuning the Database the max concurrent used connections wold be relay
> great.
>
> So I could monitor the max concurrent connections of my pool and could see if
> I have to size up/down the max database connections (that can me memory
> intensive) or if I could downsize the Pool and also the Database i could save
> Memory and costs. At the Moment the only Indicator is
> maxBorrowWaitDuration=PT3.016S,
>
> But this can only tell me hat at the Moment the pool reached its max (because
> I set maxTotal to 1) my normal Case is to have up to 20 Pools of different
> Applications that connect to one instance of MariaDB and the output of
> maxBorrowWaitDuration is 0. So I only know I would be able to downsize the
> pool but I have no hint how to size the pool best.
> This Statistical Data should be also printed in the toString() Method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
