jmeter-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 60749] New: OOM when using jdbcsampler caused by perConnCache
Date Mon, 20 Feb 2017 09:19:25 GMT

            Bug ID: 60749
           Summary: OOM when using jdbcsampler  caused by perConnCache
           Product: JMeter
           Version: 3.0
          Hardware: All
                OS: All
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Main
  Target Milestone: ---

Created attachment 34766
the method "getPreparedStatement" in class AbstractJDBCTestElement.

Encounter OOM when using jdbcsampler concurrently.
  Looking into the dump with hat, I find object "perConnCache" held a lot of
retained heap. (Sorry for not saving the dump file)
    Following is the definition of perConnCache in class
     *  Cache of PreparedStatements stored in a per-connection basis. Each
entry of this
     *  cache is another Map mapping the statement string to the actual
     *  At one time a Connection is only held by one thread
    private static final Map<Connection, Map<String, PreparedStatement>>
perConnCache =
            new ConcurrentHashMap<Connection, Map<String,
    The param "connection" is from the method "getConnection()" which in DBCP2.

    Jmeter3 using DBCP2 as connections pool instead of excalibur(which Jmeter2
use). Then I dig into the code in class PoolingDataSource which in DBCP2..
    public Connection getConnection() throws SQLException {
        try {
            C conn = _pool.borrowObject();
            if (conn == null) {
                return null;
            return new PoolGuardConnectionWrapper<>(conn);
        } catch(SQLException e) {
    As the above,the method "getConnection"  will return new
PoolGuardConnectionWrapper<>(conn) which could generate different hashcode for
the  conn returned.  So the key "connection" will not exist in the
perConnCache. then it will put the "new conn" into the perConnCache,which cause
memory leak. Looking the method "getPreparedStatement" in class
AbstractJDBCTestElement.(attached bug2).

You are receiving this mail because:
You are the assignee for the bug.
View raw message