Bamboo HikariCP properties

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

The information provided on this page is for reference only. The provided values are the ones used by Bamboo by default and do not represent a recommendation to other applications. Please reach out to Atlassian Support in case you have questions about overall DB properties in Bamboo. You can also explore the Atlassian Community for further help.


HikariCP is a solid high-performance JDBC connection pool. A connection pool is a cache of database connections maintained so that the connections can be reused when future requests to the database are required. Connection pools may significantly reduce the overall resource usage. - You can find out more here. 


These are the Atlassian HikariCP configuration properties that are set by default in the bamboo.cfg.xml configuration file.

<property name="hibernate.hikari.idleTimeout">120000</property>
<property name="hibernate.hikari.maximumPoolSize">170</property>
<property name="hibernate.hikari.minimumIdle">3</property> // When minimumIdle is not set it won't limit connections. It will consider the maximumPoolSize already set which is recommended.
<property name="hibernate.hikari.registerMbeans">true</property>

From Bamboo 9.4, the following properties are also added to the default Bamboo configuration file via BAM-22453 - Getting issue details... STATUS . You can also add such properties to prior versions of Bamboo normally.

<property name="hibernate.hikari.connectionTimeout">30000</property>
<property name="hibernate.hikari.leakDetectionThreshold">0</property>


Controls the maximum amount of time that a connection is allowed to sit idle in the pool. This setting only applies when minimumIdle is defined to be less than maximumPoolSize. Idle connections will not be retired once the pool reaches minimumIdle connections. Whether a connection is retired as idle or not is subject to a maximum variation of +30 seconds, and an average variation of +15 seconds. A connection will never be retired as idle before this timeout. A value of 0 means that idle connections are never removed from the pool. The minimum allowed value is 10000ms (10 seconds). Default: 120000 (2 minutes)


Controls the maximum size that the pool is allowed to reach, including both idle and in-use connections. This value will determine the maximum number of actual connections to the database backend. A reasonable value for this is best determined by your execution environment. When the pool reaches this size, and no idle connections are available, calls to getConnection() will block for up to connectionTimeout milliseconds before timing out. Please read about HirakiCP's pool sizingDefault: 170


Controls the minimum number of idle connections that HikariCP tries to maintain in the pool. If the idle connections dip below this value and the total connections in the pool are less than maximumPoolSize, HikariCP will make the best effort to add additional connections quickly and efficiently. However, for maximum performance and responsiveness to spike demands, we recommend not setting this value and instead allowing HikariCP to act as a fixed-size connection pool. Default: 3


Controls whether or not JMX Management Beans ("MBeans") are registered or not. Default: true


Controls the maximum number of milliseconds that Bamboo will wait for a connection from the pool. If this time is exceeded without a connection becoming available, an SQL Exception will be thrown. The lowest acceptable connection timeout is 250 ms. Default: 30000 (30 seconds)


Controls the maximum lifetime of a connection in the pool. An in-use connection will never be retired, only when it is closed will it then be removed. On a connection-by-connection basis, minor negative attenuation is applied to avoid mass extinction in the pool. A value of 0 indicates no maximum lifetime (infinite lifetime), subject of course to the idleTimeout setting. The minimum allowed value is 30000ms (30 seconds). Default: 1800000 (30 minutes)


Controls the amount of time that a connection can be out of the pool before a message is logged indicating a possible connection leak. A value of 0 means leak detection is disabled. The lowest acceptable value for enabling leak detection is 2000 (2 seconds). Default: 0 (disabled)


According to Hikari Pool Sizing and Github HikariCP:

  • HikariPool does expose the number of active connections, but it's only for JMX.
  • HikariDataSource doesn't expose any way to get the HikariPool.
  • Hikari doesn't offer any type of listener for pool interactions, like trying to track when connections are checked in and out.
  • Hikari prefers using a DataSource, per their documentation.
  • Some functionality, like statement caching, needs to be configured in the DataSource's properties; Hikari itself doesn't offer that functionality.

Database pooling is now handled by HikariCP for the 4.0 release.

The properties are:


The number of connections the pool tries to keep open and idle. By default, idle connections are not eagerly created (they will be replaced (up to this value) fairly quickly – ~15 sec on average, or immediately if requests outnumber available connections).


The maximum number of connections in the pool. (4 partitions each with 20 connections), so the default maximum has not changed.

  • Replaces the combination of db.pool.partition.connection.maximum and db.pool.partition.count.

The number of seconds the pool will wait for a connection to become available.

  • Replaces db.pool.connection.timeout

The number of seconds the pool will allow a connection to remain idle before closing it.

  • Replaces db.pool.idle.maxAge, which was previously configured in minutes.
  • Support cases suggest some installations are connected to databases with server-side idle timeouts of less than a minute

The number of minutes a connection is allowed to remain open before the system flags it as “leaked” and logs a warning.

  • This is disabled by default because long-running tasks like database migration, which can keep connections open for a very long time, would result in false positives.
  • For production instances, this generally should not be set. Plugin developers, on the other hand, might consider applying a short timeout (1) here to help police the database connection usage of their plugins.
db.pool.timeout.lifetime30The number of minutes a connection is allowed to remain open. When this timeout is exceeded, the next time the connection is released to the pool it is closed, and a new connection is opened to replace it

The following settings have been removed without replacement:

  • db.pool.acquireIncrement - HikariCP opens connections one at a time, as needed;
  • db.pool.cache.statements - HikariCP does not offer statement caching;
  • db.pool.idle.testInterval - HikariCP tests connections when they’re leased, not on a timer;
  • db.pool.connection.threshold - HikariCP doesn’t have a percentile idle threshold;
  • db.pool.size.idle - can be used to keep a fixed number of connections idle;
  • db.pool.threads - HikariCP does not use extra threads to “aid” connection release;

Last modified on Sep 20, 2023

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.