HikariCP NullPointerException

Question

We are trying to integrate the HikariCP (release 2.4.4) into our application. After some time of usage the pool fails to acquire new connections throwing:

    java.lang.NullPointerException
        at com.zaxxer.hikari.pool.PoolBase.setNetworkTimeout(PoolBase.java:464) ~[HikariCP-2.4.4.jar:?]
        at com.zaxxer.hikari.pool.PoolBase.isConnectionAlive(PoolBase.java:131) ~[HikariCP-2.4.4.jar:?]
        at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:171) ~[HikariCP-2.4.4.jar:?]
        at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:147) ~[HikariCP-2.4.4.jar:?]
        at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:83) ~[HikariCP-2.4.4.jar:?]

The jdbc driver we are using is ojdbc-7 with version 12.1.0.2. The pool uses following configuration:

    allowPoolSuspension.............false
    autoCommit......................false
    catalog.........................null
    connectionInitSql..............."BEGIN EXECUTE IMMEDIATE 'SET ROLE SOME_ROLE IDENTIFIED BY SOME_PASSWORD '; END;"
    connectionTestQuery............."SELECT 1 FROM DUAL"
    connectionTimeout...............15000
    dataSource......................null
    dataSourceClassName.............null
    dataSourceJNDI..................null
    dataSourceProperties............{v$session.machine=host, password=<masked>, v$session.program=my application}
    driverClassName................."oracle.jdbc.OracleDriver"
    healthCheckProperties...........{}
    healthCheckRegistry.............null
    idleTimeout.....................60000
    initializationFailFast..........true
    isolateInternalQueries..........false
    jdbc4ConnectionTest.............false
    jdbcUrl........................."jdbc:oracle:thin:@//host.company.com:1521/database.company.com"
    leakDetectionThreshold..........1800000
    maxLifetime.....................0
    maximumPoolSize.................18
    metricRegistry..................null
    metricsTrackerFactory...........null
    minimumIdle.....................2
    password........................<masked>
    poolName........................"TEST_POOL"
    readOnly........................false
    registerMbeans..................false
    scheduledExecutorService........null
    threadFactory...................null
    transactionIsolation............null
    username........................"USER_NAME"
    validationTimeout...............5000

Is it a bug or a missconfiguration?

Answer 1

I'm not 100% sure, but it looks like either:

• You are evicting a connection after you have called close(), which is not allowed. Or..
• You are evicting a connection and then calling close(), which is not allowed.

When you evict a connection, you must be the owner of that connection (obtained from getConnection(), and subsequently you must not close() the connection (it will be closed automatically). And as explained above, if you have called close() already, the connection is already back in the pool and it is not valid to evict it, as you are no longer the owner.

EDIT: Let me be clearer. From studying how this exception could be reached it seems clear that you are first closing the connection, and secondly evicting the connection. The reverse (evict and then close) would not result in this error.

This is known as "use after return" and is similar to "use after free" bugs in languages without garbage collection. When you close a connection, it is returned to the pool. From that instant the connection is available to be claimed by another thread -- the caller of close() is no longer the owner.

This is exactly analogous to calling free() on memory in C/C++. Instantly after doing so the memory is available to be claimed by another caller -- the caller of free() is no longer the owner. In the C/C++ case, if you continue to use a reference to the freed memory you risk corrupting data of another thread that has now allocated it.

In the case of nearly any pooling library in Java (connection or otherwise), once you release an object back to the pool you are no longer the owner. Nothing can prevent you from retaining a reference to the returned object.

In this case, once you have called close(), the object is returned to the pool instantly. If another thread obtains the connection legally from the pool (getConnection()), while at the same time the previous owner calls evict(), you will easily run into this issue.

We may choose to harden this code path (or not). HikariCP is not particularly paternalistic philosophically; favoring documentation over code. For example, if you pass a null into evict() you will be met with an NPE somewhere. Could we check for null and ignore it? Sure. Multiply that approach across the codebase and it could easily grow by 20%. Or, how about don't do that, developer?

It is a fairly simple contract:

• You can only evict a connection that you own.
• As soon as you have closed a connection, you no longer own it.