brettwooldridge/hikaricp

光 HikariCP・A solid, high-performance, JDBC connection pool at last.

hikaricp's Issues

it don't work :(

I'm using my custom ClassLoader (nothing special, just this)

            ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
            Thread.currentThread().setContextClassLoader(new ClassLoader(contextClassLoader) {
            });

Seems like bytecode modifications doesn't take effect :(

            IHikariConnectionProxy proxyConnection = ProxyFactory.getProxyConnection(this, connection, transactionIsolation, isAutoCommit, isReadOnly, catalog);
            proxyConnection.resetConnectionState();

proxyConnection is null (seems like no code generation affected) !!!

        JavassistProxyFactory.initialize();
        HikariConfig config = new HikariConfig();
        setBeanValues(properties, config);
        config.setPassword(null);
        config.setUsername(null);
        config.setDataSource(dataSource);
        return new HikariDataSource(config);

removing custom classloader fixes issue

Is it possible to have performance comparison with Tomcat-JDBC

Hi,

Tomcat guys written another pool and that code base is much more recent. It should be interesting to include this in the benchmark.

http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

HikariCP as JNDI Datasource

I have trying to test HikariCP as jndi datasource, but i cannot find the way to add it as jndi datasource in tomcat 7.
If it's possible can you provide the configuration or if not can you add this feature ?

[1.3.4] ClassNotFoundException

http://hastebin.com/hilotulifu.avrasm - I'm getting this on startup. But it's limited to the 1.3.4-Version. With the 1.3.3 Version everything works just fine, but with the new 1.3.4 Version I can't start the connection pool.

I would really appreciate some help, thanks!

MBean Stuff

Hi,

Not sure if also related to the previous issue, but on shut-down of the app, I now get get:

[13:22:58.900] [               ] [DEVELOPMENT] [WARN ] [com.zaxxer.hikari.pool.HikariMBeanElf   ] [99  ] - Unable to unregister management beans.
javax.management.InstanceNotFoundException: com.zaxxer.hikari:type=Pool (corePool)
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) ~[na:1.8.0]
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427) ~[na:1.8.0]
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415) ~[na:1.8.0]
    at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546) ~[na:1.8.0]
    at com.zaxxer.hikari.pool.HikariMBeanElf.unregisterMBeans(HikariMBeanElf.java:90) ~[HikariCP-1.3.8.jar:na]
    at com.zaxxer.hikari.pool.HikariPool.shutdown(HikariPool.java:239) [HikariCP-1.3.8.jar:na]
    at com.zaxxer.hikari.HikariDataSource.shutdown(HikariDataSource.java:225) [HikariCP-1.3.8.jar:na]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0]
    at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0]
    at org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCustomDestroyMethod(DisposableBeanAdapter.java:349) [spring-beans-4.0.3.RELEASE.jar:4.0.3.RELEASE]

-=david=-

connectionTimeout implementation default different from documentation default

The documentation says the default connectionTimeout is 30000 ms.
The implementation actually defaults the connectionTimeout to 5000 ms.

Also, the JavaDoc for connectionTimeout is actually the JavaDoc for connectionTestQuery

NullPointerException within HikariDataSource.shutdown()

I have a encountered a NullPointerException using the close method of HikariDataSource (1.3.2) when using it as a spring bean.

Following use case. A declared a HikariCP data source as a spring bean in Java config manner. Here is the code:

@Bean(destroyMethod = "close")
  public HikariDataSource dataSource(@Value("${db.name}") String databaseName,
    @Value("${db.user}") String user, @Value("${dashboard.db.pass}") String password,
    @Value("${db.login.timeout.sec}") int loginTimeoutSec,
    @Value("${db.connect.timeout.ms}") final int connectionTimeoutMs,
    @Value("${db.max.pool.size}") final int maxPoolSize,
    @Value("${db.min.pool.size}") final int minPoolSize,
    @Value("${db.test.query}") final String connectionTestQuery,
    @Value("${db.acq.inc}") final int acquireIncrement) throws SQLException {

    MysqlDataSource mysqlDataSource = new MysqlDataSource();
    mysqlDataSource.setDatabaseName(databaseName);
    mysqlDataSource.setUser(user);
    mysqlDataSource.setEncoding("UTF-8");
    mysqlDataSource.setUseUnicode(true);
    if (!Strings.isNullOrEmpty(password)) {
      mysqlDataSource.setPassword(Aes.decrypt(password));
    }

    HikariDataSource dataSource = new HikariDataSource();
    dataSource.setLoginTimeout(loginTimeoutSec); // sec
    dataSource.setPoolName("dashboard-server-pool");
    dataSource.setConnectionTimeout(connectionTimeoutMs); // ms
    dataSource.setMaximumPoolSize(maxPoolSize);
    dataSource.setMinimumPoolSize(minPoolSize);
    dataSource.setJdbc4ConnectionTest(false);
    dataSource.setConnectionTestQuery(connectionTestQuery);
    dataSource.setAcquireIncrement(acquireIncrement);
    dataSource.setAcquireRetries(1);
    dataSource.setAcquireRetryDelay(1000); // ms
    dataSource.setDataSource(mysqlDataSource);

    return dataSource;
  }

As you can see, I am using "close()" as Spring destroy method when shutting down the app. The "close()" effectively does nothing more then delegating to "shutdown()". When shutting down the app, a NullPointerException was raised for HikariDataSource:167.

The code there shows that the internal pool instance was not instantiated at that time.

/**
     * Shutdown the DataSource and its associated pool.
     */
    public void shutdown()
    {
        boolean shutdown = isShutdown;
        isShutdown = true;
        if (!shutdown)
        {
            pool.shutdown();
            pool = null;
        }
    }

I noticed that this is a rare use case, because it only happened because Spring started up but no connection had been used so far, so no pool was created and when the app shuts down the NullPointer was raised.

I managed to workaround this splitting the declaration up into HikariConfig and HikariDataSource. Here is the code:

@Bean(destroyMethod = "close")
  public HikariDataSource dataSource(@Value("${db.name}") String databaseName,
    @Value("${db.user}") String user, @Value("${db.pass}") String password,
    @Value("${db.login.timeout.sec}") int loginTimeoutSec,
    @Value("${db.connect.timeout.ms}") final int connectionTimeoutMs,
    @Value("${db.max.pool.size}") final int maxPoolSize,
    @Value("${db.min.pool.size}") final int minPoolSize,
    @Value("${db.test.query}") final String connectionTestQuery,
    @Value("${db.acq.inc}") final int acquireIncrement) throws SQLException {

    MysqlDataSource mysqlDataSource = new MysqlDataSource();
    mysqlDataSource.setDatabaseName(databaseName);
    mysqlDataSource.setUser(user);
    mysqlDataSource.setEncoding("UTF-8");
    mysqlDataSource.setUseUnicode(true);
    if (!Strings.isNullOrEmpty(password)) {
      mysqlDataSource.setPassword(Aes.decrypt(password));
    }

    HikariConfig config = new HikariConfig();
    config.setPoolName("dashboard-server-pool");
    config.setConnectionTimeout(connectionTimeoutMs); // ms
    config.setMaximumPoolSize(maxPoolSize);
    config.setMinimumPoolSize(minPoolSize);
    config.setJdbc4ConnectionTest(false);
    config.setConnectionTestQuery(connectionTestQuery);
    config.setAcquireIncrement(acquireIncrement);
    config.setAcquireRetries(1);
    config.setAcquireRetryDelay(1000); // ms
    config.setDataSource(mysqlDataSource);

    HikariDataSource dataSource = new HikariDataSource(config);
    dataSource.setLoginTimeout(loginTimeoutSec); // sec

    return dataSource;
  }

The constructor call of HikariDataSource that takes the HikariConfig parameter initialises the pool within the constructor, so the NullPointerException was not raised during shutdown.

My question is, am I missing something obvious here or is the different behaviour of the HikariDataSource constructors the desired behaviour? Is the initialisation of the pool instance missing from no arg constructor?

Consider adding HikariConfig#setTransactionIsolation

I'm using HikariCP together with Spring and it would be nice to specify a default transaction level for handed out connections.

Called like:

HikariConfig config = new HikariConfig();
// Taking transaction name (Connection.TRANSACTION_REPEATABLE_READ)
// so that configuration in properties file is readable
config.setTransactionIsolation("TRANSACTION_REPEATABLE_READ");

If the underlying DataSource would allow it, HikariConfig#addDataSourceProperty could be used, but in the case of postgres, PGSimpleDataSource has no appropriate setter.

Spring 3.2/Hibernate 4.3: Actual connection is closed upon return to pool

I am using Spring 4 with Hibernate 4.3 as a JPA provider.

Hibernate does not release connection back to pool when execute INSERT or UPDATE statement.

I tested with c3p0 and tomcat-jdbc have not this problem.

Here is my config:

<bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource">
    <constructor-arg>
        <bean class="com.zaxxer.hikari.HikariConfig">
            <constructor-arg>
                <props>
                    <prop key="dataSource.url">${datasource.jdbcUrl}</prop>
                    <prop key="dataSource.user">${datasource.user}</prop>
                    <prop key="dataSource.password">${datasource.password}</prop>
                    <prop key="dataSource.cachePrepStmts">true</prop>
                    <prop key="dataSource.prepStmtCacheSize">250</prop>
                    <prop key="dataSource.prepStmtCacheSqlLimit">2048</prop>
                </props>
            </constructor-arg>
            <property name="dataSourceClassName" value="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" />
            <property name="minimumPoolSize" value="5" />
            <property name="maximumPoolSize" value="15" />
            <property name="acquireIncrement" value="1" />
            <property name="maxLifetime" value="1800000" />
        </bean>
    </constructor-arg>
</bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="dataSource" ref="dataSource" />
    <property name="persistenceUnitName" value="DefaultDS"/>
    <property name="jpaProperties">
        <props>
            <prop key="hibernate.dialect">org.hibernate.dialect.MySQL5Dialect</prop>

            <prop key="hibernate.show.sql">false</prop>
            <prop key="hibernate.format_sql">false</prop>
            <prop key="hibernate.use_sql_comments">false</prop>
        </props>
    </property>
</bean>

NPE in Hibernate when Connection accessed from thread that did not create it

Hi,

Just bumped up to the latest version (from 1.2.1) and now I'm getting this error, which is causing the transaction to rollback. This was okay on 1.2.1 (no code changes, just a version bump).

-=david=-

java.lang.NullPointerException: null
at com.zaxxer.hikari.proxy.ConnectionProxy._checkClosed(Unknown Source) ~[HikariCP-1.2.3.jar:na]
at com.zaxxer.hikari.proxy.ConnectionJavassistProxy.getAutoCommit(ConnectionJavassistProxy.java) ~[na:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_45]
at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_45]
at org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy$LazyConnectionInvocationHandler.invoke(LazyConnectionDataSourceProxy.java:376) ~[spring-jdbc-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at com.sun.proxy.$Proxy21.getAutoCommit(Unknown Source) ~[na:na]
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:68) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1431) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61) ~[hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
at org.springframework.orm.jpa.DefaultJpaDialect.beginTransaction(DefaultJpaDialect.java:67) ~[spring-orm-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:110) ~[spring-orm-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:380) ~[spring-orm-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
Wrapped by: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is java.lang.NullPointerException
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:430) ~[spring-orm-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:373) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:420) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:257) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136) ~[spring-tx-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.data.jpa.repository.support.LockModeRepositoryPostProcessor$LockModePopulatingMethodIntercceptor.invoke(LockModeRepositoryPostProcessor.java:92) ~[spring-data-jpa-1.5.0.M1.jar:na]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) ~[spring-aop-4.0.1.BUILD-SNAPSHOT.jar:4.0.1.BUILD-SNAPSHOT]
at com.sun.proxy.$Proxy109.save(Unknown Source) ~[na:na]

Exception during keep alive check

Right after updating from 1.2.4 to 1.2.6 i've encountered with a strange behaviour.
The DB (MySQL) itself is okay. A bug, i guess?
So here it is (these are the postponed tasks):

[ERROR 14:40:52]: Exception during keep alive check.  Connection must be dead.
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 746,568 milliseconds ago.  The last packet sent successfully to the server was 2 milliseconds ago.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1129)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3720)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3609)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4160)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2617)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2778)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2819)
        at com.mysql.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:5355)
        at com.zaxxer.hikari.proxy.ConnectionJavassistProxy.setAutoCommit(ConnectionJavassistProxy.java)
        at com.zaxxer.hikari.HikariPool.isConnectionAlive(Unknown Source)
        at com.zaxxer.hikari.HikariPool.getConnection(Unknown Source)
        at com.zaxxer.hikari.HikariDataSource.getConnection(Unknown Source)
        ...
        ...
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:744)
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
        at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3166)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3620)
        ... 25 more

The database log also contains this, many of them.
Also, i've seen it before, within previous releases of HikariCP.
Don't know if it is a normal behaviour, but i never seen so much "aborted connections" in log when been using BoneCP, for example.

140115 15:10:02 [Warning] Aborted connection 216 to db: 'server' user: 'user' host: 'localhost' (Unknown error)
140115 15:10:32 [Warning] Aborted connection 217 to db: 'server' user: 'user' host: 'localhost' (Unknown error)
140115 15:11:02 [Warning] Aborted connection 218 to db: 'server' user: 'user' host: 'localhost' (Unknown error)
140115 15:11:32 [Warning] Aborted connection 219 to db: 'server' user: 'user' host: 'localhost' (Unknown error)

Requirements not aligned

The requirements of HikariCP are unclear as the documentation found at the following site do not match those documented on GitHib:

http://brettwooldridge.github.io/HikariCP/

Java 7 is stated as a requirement at the aforementioned link, yet GitHub states Java 6+ is supported.

NPE for null password

Given the following config

<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
   <Arg></Arg>
   <Arg>jdbc/DSTest</Arg>
   <Arg>
     <New class="com.zaxxer.hikari.HikariDataSource">
       <Arg>
          <New class="com.zaxxer.hikari.HikariConfig">
             <Set name="minimumPoolSize">5</Set>
             <Set name="maximumPoolSize">50</Set>
             <Set name="dataSourceClassName">org.h2.jdbcx.JdbcDataSource</Set>
             <Call name="addDataSourceProperty">
                <Arg>url</Arg>
                <Arg>${jdbc.url}</Arg>
             </Call>
             <Call name="addDataSourceProperty">
                <Arg>user</Arg>
                <Arg>sa</Arg>
             </Call>
             <Call name="addDataSourceProperty">
                <Arg>password</Arg>
                <Arg></Arg>
             </Call>
          </New>
       </Arg>
    </New>
  </Arg>
</New>

Caused by: java.lang.NullPointerException
    at java.util.Hashtable.put(Hashtable.java:394)
    at com.zaxxer.hikari.HikariConfig.addDataSourceProperty(HikariConfig.java:311)

is encountered.

HikariPool does not implement DynamicMBean

Hi,

Java 1.8u5
HikariCP 1.3.7
Spring 4.0.3.RELEASE

Upgraded from 1.3.6 to 1.3.7 of HikariCP. I now get this exception on startup:

16:12:01.258] [               ] [DEVELOPMENT] [WARN ] [com.zaxxer.hikari.pool.HikariMBeanElf   ] [69  ] - Unable to register management beans.
javax.management.NotCompliantMBeanException: MBean class com.zaxxer.hikari.pool.HikariPool does not implement DynamicMBean, and neither follows the Standard MBean conventions (javax.management.NotCompliantMBeanException: Class com.zaxxer.hikari.pool.HikariPool is not a JMX compliant Standard MBean) nor the MXBean conventions (javax.management.NotCompliantMBeanException: com.zaxxer.hikari.pool.HikariPool: Class com.zaxxer.hikari.pool.HikariPool is not a JMX compliant MXBean)
    at com.sun.jmx.mbeanserver.Introspector.checkCompliance(Introspector.java:176) ~[na:1.8.0_05]
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:317) ~[na:1.8.0_05]
    at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) ~[na:1.8.0_05]
    at com.zaxxer.hikari.pool.HikariMBeanElf.registerMBeans(HikariMBeanElf.java:60) ~[HikariCP-1.3.7.jar:na]
    at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:128) [HikariCP-1.3.7.jar:na]
    at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:91) [HikariCP-1.3.7.jar:na]
    at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:69) [HikariCP-1.3.7.jar:na]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.8.0_05]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [na:1.8.0_05]
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [na:1.8.0_05]
    at java.lang.reflect.Constructor.newInstance(Constructor.java:408) [na:1.8.0_05]
    at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) [spring-beans-4.0.3.RELEASE.jar:4.0.3.RELEASE]
    at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:125) [spring-beans-4.0.3.RELEASE.jar:4.0.3.RELEASE]

Meaning of "Value was returned to the bag that was not borrowed"?

I'm occasionally seeing the following error from my app:

! java.lang.IllegalStateException: Value was returned to the bag that was not borrowed
! at com.zaxxer.hikari.util.ConcurrentBag.requite(ConcurrentBag.java:177) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at com.zaxxer.hikari.HikariPool.releaseConnection(HikariPool.java:199) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at com.zaxxer.hikari.proxy.ConnectionProxy.close(ConnectionProxy.java:330) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at com.mchange.v2.sql.filter.FilterConnection.close(FilterConnection.java:327) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.BasicHandle.close(BasicHandle.java:116) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.CloseInternalDoNotUseThisClass$CloseHandler.invoke(CloseInternalDoNotUseThisClass.java:36) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.SqlObject.invoke(SqlObject.java:171) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.SqlObject$1.intercept(SqlObject.java:75) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.CloseInternalDoNotUseThisClass$$EnhancerByCGLIB$$e389b236.___jdbi_close___(<generated>) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.SqlObject.close(SqlObject.java:184) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.sqlobject.SqlObjectBuilder.close(SqlObjectBuilder.java:76) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
! at org.skife.jdbi.v2.DBI.close(DBI.java:353) ~[ContentRendering-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]

What could cause this error to occur? Is this indicative of a connection leak?

NoClassDefFoundError

I don't think the main issue is from you but actually that what append:

I run some tests from Maven 3.2.1 that use your lib v1.3.3 on centos 6.5 64b.
I got a Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.zaxxer.hikari.HikariConfig. Classpath look fine with debug mode enable to maven.
It work fine on Windows and even at runtime on centos.

Do you have any clue? The only thing different is the maven lib name that start with an uppercase and everything else with a lowercase.

Maybe did you know how to force a lib to maven.

Thanks

let me supply a DataSource to wrap

i might not have url/user/password - i might just have a DataSource from JNDI
which i'd like wrapped. BoneCP, one of your competitors :) lets me do that.

logging bug in HikariMBeanElf.java

in HikariMBeanElf.java there is line:
LOGGER.error("No registered MBean for {0}.", configuration.getPoolName());

but slf4j doesn't work that way. it should just be {}.
the message i'm seeing in logs is:
No registered MBean for {0}.

Add constructor accepting HikariPool to HikariDataSource

It'd be handy to be able to construct the pool outside of the datasource.

Suppress warning message on connection death

So I had a connection die and HikariCP threw two huge warning messages into my log. Can I either suppress these or replace them with my own message? I don't really care if a connection sitting idle in the pool died, since a new one will just take its place. The first two lines from the two stack traces are below:

2014-04-30 01:00:11 [WARN] Connection com.amshulman.insight.lib.mysql.MySQLConnection@cf5011b (HikariPool-0) marked as broken because of SQLSTATE(08), ErrorCode(-1).
java.sql.SQLNonTransientConnectionException: Could not ping: unexpected end of stream, read 0bytes from 4

2014-04-30 01:00:11 [WARN] Exception during keep alive check, that means the connection must be dead.
java.sql.SQLNonTransientConnectionException: Could not ping: unexpected end of stream, read 0bytes from 4

Small suggestion

Hi,

I'm the author of BoneCP. I'm delighted at finding your project - some interesting ideas out there! Thank you for taking the time to document your techniques. Do you accept contributions? :-)

Might I suggest adding units to your config methods eg InSeconds etc, before I did this, forums were filled with people getting the units wrong, they disappeared when I made the API more explicit. In other words try to avoid the mistakes I made in my initial versions :-)

Postgres Issue

I keep getting these errors even though there are very few connections open. I changed over to DBCP and no issues.

[ERROR] com.zaxxer.hikari.HikariPool - Maximum connection creation retries exceeded: FATAL: remaining connection slots are reserved for non-replication superuser connections
org.postgresql.util.PSQLException: FATAL: remaining connection slots are reserved for non-replication superuser connections
at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:572) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:177) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:64) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:136) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:29) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:21) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:31) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.Driver.makeConnection(Driver.java:410) ~[postgresql-9.3-1100-jdbc41.jar:na]
at org.postgresql.Driver.connect(Driver.java:280) ~[postgresql-9.3-1100-jdbc41

[Question] Handling Connections

Hey brettwooldridge,

I haven't worked with connectionpools a lot, and I stumbled upon the question what I have to do in the finally-block of queries. So without a connection-pool I closed the PreparedStatement, the ResultSet and the Connection. Which of them do I have to close in the finally-block while using HikariCP as ConnectionPool?

Thanks in Advance!
Scrayos

Transaction isolation applied to running transaction in HikariPool

I am running HikariCP 1.2.4 with

HikariConfig config = new HikariConfig();
config.setUseInstrumentation(false);
config.setJdbc4ConnectionTest(true);
config.setAutoCommit(false);
config.setTransactionIsolation("TRANSACTION_REPEATABLE_READ");

Because HikariPool does not reset the autocommit flag (to its default of true) when the connection is returned to the pool, this leads to (comments inline, code from HikariPool, line 152):

Connection connection = (Connection) connectionProxy;
// if connectionProxy is not autocommiting, this will start a transaction
if (!isConnectionAlive(connection, timeout))
{
    // Throw away the dead connection, try again
    closeConnection(connectionProxy);
    timeout -= (System.currentTimeMillis() - start);
    continue;
}

if (leakDetectionThreshold > 0)
{
    connectionProxy._captureStack(leakDetectionThreshold, houseKeepingTimer);
}
// if autocommit is already false, this is a noop, transaction still running
connection.setAutoCommit(isAutoCommit);
// Exception here, because transaction is already running
connection.setTransactionIsolation(transactionIsolation);
connection.clearWarnings();

I also noticed while debugging that postgres (in my case) will perform a roundtrip to the database on

Connection#setTransactionIsolation and also on Connection#getTransactionIsolation

Maybe the transaction isloation could be cached by HikariCP and only set once on creation of the actual connection?

PropertyBeanSetter fails to set DataSource#url for some databases

Slightly older versions of H2 provide JdbcDataSource#setURL, but not JdbcDataSource#setUrl. That was corrected in a recent revision, however it will cause issues for many Hibernate users. Could PropertyBeanSetter#setTargetFromProperties be improved to handle crappy JDBC impls? ;)

I'm including a workaround in hibernate-hikaricp, for now.

Thanks!

SQL logging

Please add sql operations logging (insert, delete, update, select) like in bonecp

javax.sql.ConnectionPoolDataSource support

Current HikariCP solution contains of 2 parts

1. Codegen/Proxy related stuff to wrap java.sql.Connection to something like javax.sql.PooledConnection
2. Pool management code itself (inc thread syncronization, lifetime management etc)

Some JDBC drivers provide javax.sql.ConnectionPoolDataSource out-of the box. So bytecode generation isn't requred. I propose to split HikariCP for 2 lose-coupled parts:

1. Codegen/Proxy related stuff to generate javax.sql.DataSource to exact javax.sql.ConnectionPoolDataSource adapter
2. Pool management code to deal directly with javax.sql.ConnectionPoolDataSource api.

In this case you can use both parts if JDBC driver doesn't support javax.sql.ConnectionPoolDataSource and only second part otherwise...

Tomcat 7.0.50 shutdown issue

After updating HikariCP from 1.2.8 to 1.3.0 during shutdown Apache Tomcat 7.0.50 I'm getting these messages in catalina.log:

Mar 02, 2014 5:27:40 PM org.apache.catalina.core.StandardServer await
INFO: A valid shutdown command was received via the shutdown port. Stopping the Server instance.
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["http-apr-8080"]
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler ["ajp-apr-8009"]
Mar 02, 2014 5:27:40 PM org.apache.catalina.core.StandardService stopInternal
INFO: Stopping service Catalina
Mar 02, 2014 5:27:40 PM org.apache.catalina.core.ApplicationContext log
INFO: Closing Spring root WebApplicationContext
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@4034afa3]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@4034afa3]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@4034afa3]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@4034afa3]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/test] created a ThreadLocal with key of type [com.zaxxer.hikari.util.ConcurrentBag$1](value [com.zaxxer.hikari.util.ConcurrentBag$1@1b6f3995]) and a value of type [java.util.LinkedList](value [[com.zaxxer.hikari.proxy.ConnectionJavassistProxy@af5dd35]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["http-apr-8080"]
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["ajp-apr-8009"]
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["http-apr-8080"]
Mar 02, 2014 5:27:40 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["ajp-apr-8009"]

Question: how to fail fast on bad DB password

Hi,
If my HikariCP config has the wrong database credentials, I'd like my server to fail fast.

Seems like the only way is to wait for acquireRetries * acquireRetryDelay milliseconds, then try to call getConnection(), catch the SQLException and then exit.

Do I have that right?

Thanks,
Mark

Connections marked as broken

Hey, first of all I'm sorry for creating another Issue but it's definetely not related to new versions, but HikariCP (Or my Implementation of it) in general.

Every X. connection I get from the pool seems to be broken:
[SEVERE] [Netty IO Thread #2] WARN com.zaxxer.hikari.proxy.ConnectionProxy - Connection com.mysql.jdbc.JDBC4Connection@38dfa9cc marked as broken because of SQLSTATE(08003), ErrorCode(0): null

I just get a connection with try (Connection cn = JCProxy.getInstance().getMysqlHandler().getConnection()) { and it should be closed automatically at the end of the try-catch-block.

The strangest thing about is that every snippet of my code has its own "Interval-of-broken-Connection" as it seems. I got a Plugin for a Minecraft-Proxy-Software. In this plugin there are some Commands. In one command every 2nd connection is broken in another plugin every 3rd connection is broken ... I'm unsure if it's randomly or I am doing something wrong if you want I could send you the full code from one of the commands.

Problem with MySQL recovery

Lars Gråmark has reported a scenario where HikariCP does not seem to recover successfully after MySQL connections are killed. This bug is to provide a place to attach materials related to the issue.

lastConnectionFailure causes null pointer

I'm trying to configure Hikari, but I'm getting a null pointer right now. HikariPool line 175:

        throw new SQLException(String.format("Timeout of %dms encountered waiting for connection.", configuration.getConnectionTimeout()), lastConnectionFailure.getAndSet(null));

lastConnectionFailure is null. Perhaps a null check is warranted?

Dependency on Hibernate?

+-com.zaxxer:HikariCP:1.2.5
[info] | +-org.hibernate:hibernate-core:4.3.0.Final
[info] | | +-antlr:antlr:2.7.7
[info] | | +-dom4j:dom4j:1.6.1
[info] | | | +-xml-apis:xml-apis:1.0.b2
[info] | | |
[info] | | +-org.hibernate.common:hibernate-commons-annotations:4.0.4.Final
[info] | | | +-org.jboss.logging:jboss-logging-annotations:1.2.0.Beta1
[info] | | | +-org.jboss.logging:jboss-logging:3.1.3.GA
[info] | | |
[info] | | +-org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.0.Final
[info] | | +-org.javassist:javassist:3.18.1-GA
[info] | | +-org.jboss.logging:jboss-logging-annotations:1.2.0.Beta1
[info] | | +-org.jboss.logging:jboss-logging:3.1.3.GA
[info] | | +-org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:1.0.0.Final
[info] | | +-org.jboss:jandex:1.1.0.Final
[info] | |
[info] | +-org.javassist:javassist:3.18.1-GA
[info] | +-org.slf4j:slf4j-api:1.7.5

osgi: unit tests

Pool leaks connections open if customization/initSql fails

There seems to be slight a possibility to connection leak in the pool between acquiring a connection and adding it to the pool. Connection state reset has similar problem as well.

Steps to fix the issue (HikariPool.addConnection):

1. Obtaining of a datasource connection should be closed (try/catch) in case of a failure prior it has been added to the pool
2. initSql block should be followed by resetConnectionState in any case (try/finally)

Can't set idleTimeout to 0.

Log say: "idleTimeout is less than 30000ms, did you specify the wrong time unit? Using default instead."

Allow data source properties to be set directly in HikariConfig

Currently there are two ways of configuring data source properties:

• method addDataSourceProperty(String propertyName, Object value)
• constructor HikariConfig(String propertyFileName)

I'm configuring HikariCP with spring xml configuration and I need to set datasource properties (url, user, password).

I can't call the method addDataSourceProperty from the xml configuration and I would need a real file for the constructor. Could you add possibility to set Properties directly, e.g. method

setDriverProperties(Properties properties)

or constructor

HikariConfig(Properties properties)

[1.3.3] User is reporting overcommitted pool (600 connections at the DB)

I recently switched my Spring RESTful API data source from DriverManagerDataSource to HikariCp, but my database connections went from 20 connections to 600 connections. Is this suppose to happen?

My settings are as follows:

<bean id="jdbcDataSource"
    class="com.zaxxer.hikari.HikariDataSource" destroy-method="shutdown">
    <constructor-arg>
        <bean class="com.zaxxer.hikari.HikariConfig">
            <constructor-arg>
                <props>
                    <prop key="dataSource.url">url</prop>
                    <prop key="dataSource.user">user</prop>
                    <prop key="dataSource.password">password</prop>
                    <prop key="dataSource.cachePrepStmts">true</prop>
                    <prop key="dataSource.prepStmtCacheSize">250</prop>
                    <prop key="dataSource.prepStmtCacheSqlLimit">2048</prop>
                    <prop key="dataSource.useServerPrepStmts">true</prop>
                </props>
            </constructor-arg>
            <property name="dataSourceClassName" value="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" />
        </bean>
    </constructor-arg>
</bean>

<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
    <property name="dataSource" ref="jdbcDataSource" />
</bean>

JavaAssist and Java 8

I'm getting a strange error when instantiating hikariCP when using java 8.
Here's a description of the problem:
http://www.symphonious.net/2014/03/21/javassist-java-8-invalid-constant-type-15/

The stacktrace is here:
at com.zaxxer.hikari.HikariConfig.(HikariConfig.java:82)
...
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: invalid constant type: 15
at com.zaxxer.hikari.proxy.JavassistProxyFactory.(JavassistProxyFactory.java:63)
... 6 more
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: invalid constant type: 15
at com.zaxxer.hikari.proxy.JavassistProxyFactory.(JavassistProxyFactory.java:103)
at com.zaxxer.hikari.proxy.JavassistProxyFactory.(JavassistProxyFactory.java:57)
... 6 more
Caused by: java.lang.RuntimeException: java.io.IOException: invalid constant type: 15

Allow DataSource configuration via driverClass

Setting the DataSource using e.g. org.postgresql.ds.PGSimpleDataSource seems to be less portable/ideal when supporting multiple DBs at the same time. E.g. PGSimpleDataSource does not provide for a JDBC url to be specified. Other pool implementations (e.g. BoneCP) provide more of an abstractions level so that I can set the DB properties across the various implementations e.g.

• jdbcUrl
• username
• password
• ...

Add Spring setup to documentation (ideas included)

Hey @brettwooldridge, finally getting around to playing with HikariCP/Hibernate on a non-profit I support (nlfw.org). Working beautifully so far. Very, very glad to delete C3P0 from the dependencies ;)

For what it's worth, this is my Spring configuration. It might be beneficial to throw something like this in your docs.

https://gist.github.com/brmeyer/bbb8688658dd71752738

Note that I'm using the annotation-based Spring configuration, but the concepts would be similar through XML.

Just thought I'd throw that out there!

Automatic rollback

Following my previous question on SO it would be nice to have automatic rollback for checked-in connections when their autoCommit is set to false.

UTF-8 character encoding

I can't seem to be able to get data encoded in UTF-8 (cyrilic , arabic alphabets etc) from my MySQL database. Everything else works correctly and as expected.
Without HikariCP (no connection pooling) I used "useUnicode=true&characterEncoding=UTF-8" as a property for my connection and it worked.
With HikariCP i tried something similar for the configuration:
config.addDataSourceProperty("url", "jdbc:mysql://localhost:3306/db?useUnicode=true&characterEncoding=UTF-8");
I also tried using the following:
config.addDataSourceProperty("characterEncoding",Charsets.UTF_8.name());
config.addDataSourceProperty("useUnicode","true");
Neither worked, the cyrilic characters were shown as ???.
My MySQL version is 5.5.27, but like i said without using connection pooling the character were shown correctly.
Any suggestions/ideas?

Support forceClose for Sybase JConnect 7.0

ConnectionProxy.java implements a SQLState check to determine if a connection is in a broken state.

The current implementation supports the SQL 2003 standard and Postgres specific codes.

The Sybase JConnect driver has its own proprietary SQL state codes which are documented in the programmers manual available at http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc39001.0700/pdf/prjdbc0700.pdf

The state codes which should be treated as connection errors are:
"JZ0C0" - Connection is already closed
"JZ0C1" - An IOException occurred which closed the connection

Unfortunately the JConnect driver chains JZ0C1 inside a JZ006 exception - as documented by the pdf above. I have also experienced behavior where JZ0C0 has been chained inside a JZ006, although this is not mentioned by the spec. In spite of the description given, JZ0C0 can appear without invoking connection.close() explicitly.

The spec suggests that if a JZ006 occurs without any chained exceptions that the connection is still in a usable state - although I have never seen this particular scenario occur in my (limited) usage of the driver to date.

This suggests that a robust implementation would be to add both JZ0C0 and JZ0C1 to the SQL_ERRORS set and then change the behavior of checkException to check both sqle.sqlState and sqle.getNextException.sqlState (when defined) against the error list. JZ006 should not be treated as a connection error.

Make metrics tracker optional

Currently CodaHaleMetricsTracker is required at compile/runtime to be present even when metrics are not recorded although pom.xml states scope provided. It would not help even if dependency would be marker as optional (as it should, same goes for hibernate).

I think that it would be better to initialize it from a given classname instead of boolean so that other metrics implementations could be used as well. That would fix this problem at the same time.

Javassist to ASM

What does you think about migration from Javassist to ASM? I can help You to rewrite bytecode generation procedures.

[1.2.8] Housekeeping timer thread never terminating / Connections remain opened

Hi,

I'm using HikariCP within a GlassFish 3.x application server. Datasources are created on demand, kept available for some time and closed after a certain timeout.

HikariPool#shutdown() currently isn't implemented, thus every datasource ever
created (and removed) "leaks" the associated connections as well as one timer
thread.

Probably, shutdown() should

• close all connections
• terminate the associated housekeeping timer thread

Support for DataSource#setLogWriter

To see what is going on with the underlying DataSource (PGSimpleDataSource in my case) I use DataSource#setLogWriter. However, I did not find a way to do this with HikariCP.

What I tried:

PrintWriter logWriter = ...;

HikariConfig config = new HikariConfig();
// logWriter is first converted to String, so this does not work
config.addDataSourceProperty("logWriter", logWriter);
// other properties ...

HikariDataSource connectionPool = new HikariDataSource(config);
// Implementation does nothing
connectionPool.setLogWriter(logWriter);

Are there any plans to support this?

Thank you in advance and for your work so far, HikariCP is awesome. :)

Suggestions for Spring + JPA as persistence.xml?

Stumbled on this interesting tool today. Do you have guidance for expressing the appcontext config instead as a persistence.xml - following your MySQL example using JPA (2.x), Hibernate (4.x)?

IndexOutOfBoundsException in close()

There's a little problem lying in ConnectionProxy.close().

Example case:

try(final Connection con = Pool.getInstance().getConnection())
{
    // e.g forgot to close.
    con.createStatement();
    con.createStatement();
}
catch (SQLException e)
{
    e.printStackTrace();
}

This one leads to this:

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
        at java.util.ArrayList.rangeCheck(ArrayList.java:635)
        at java.util.ArrayList.get(ArrayList.java:411)
        at com.zaxxer.hikari.proxy.ConnectionProxy.close(Unknown Source)

The cause of this is simple. The size of openStatements stored as a constant.
Then, when the statement is closed (unregisterStatement) - it'll be removed from the List and therefore we cannot use the size constant again which is used for loop as it is points to invalid index (from now).

p.s Shouldn't there be a option for logging such "unclosed" resources? :)