commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (Jira)" <>
Subject [jira] [Commented] (POOL-350) Add option for not executing "hasBorrowWaiters()" while returning objects
Date Sat, 05 Oct 2019 23:43:00 GMT


Phil Steitz commented on POOL-350:

How about adding two config parameters



Maybe with better names.  The way it works now is reuseCapacity is called on return only. 
I can see wanting to turn this off in some applications (though it risks liveness problems). 
Having the option to have the evictor do it might work for some workloads.

Another option is to make it more efficient.  I played a little with introducing a map of
atomic ints maintaining waiter counts so you don't have to walk the pool list and get the
locks on the LBDs; but I could not demonstrate better performance that way.  Could be my
benchmarks were misleading though and that is another option here.

> Add option for not executing "hasBorrowWaiters()" while returning objects
> -------------------------------------------------------------------------
>                 Key: POOL-350
>                 URL:
>             Project: Commons Pool
>          Issue Type: New Feature
>    Affects Versions: 2.6.0
>         Environment: h5. uname -a:
> Linux VMS26239 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 UTC 2015 x86_64 x86_64
x86_64 GNU/Linux
> *Java version:*
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
>            Reporter: zhu chen
>            Priority: Critical
>              Labels: easyfix
> h2. Phenomena:
> I'm recently leveraging commons-pool as my Redis connection pool in my project, however,
the pain is that when my system is dealing with over thousands of Redises,  CPU load become
such high. By checking JVM through JFR(FlightRecorder), it turned out the hot method was "{color:#FF0000}hasBorrowWaiters(){color}",
which is invoked by "{color:#FF0000}returnObject(){color}" each time.
> That means the system will go through over *thousands*(the number will grow as well as
my system) of keys after *each* object's *return*, what's worse, the program is running concurrently,
which, obviously cause a huge CPU load.
> h2. Expect:
> I was wondering if we could add a config for optionally run this "hasBorrowWaiters()"
each time when we return an object.

This message was sent by Atlassian Jira

View raw message