Unable to monitor HikariCP pools created with play-slick due to conflicting poolName

[balagez]

There's a bug in Slick's HikariCP code which makes Slick use the name parameter of forConfig as the pool name. If an application that uses play-slick has more than one connection pools, because of this Slick bug, all pools are created with the same db pool name. This is serious problem if we want to monitor HikariCP connection pools because HikariCP registers MBeans using the poolName and these names are conflicting, so only the first MBean is registered successfully, the rest of them fail.

Of course the ultimate solution would be to fix the Slick bug, but until then, maybe play-slick could do something to provide Slick with the correct pool names.

Example play-slick configuration based on the Play framework documentation:

slick.dbs.read.driver = "slick.driver.MySQLDriver$"
slick.dbs.read.db.driver = "com.mysql.jdbc.Driver"
slick.dbs.read.db.url = "jdbc:mysql://localhost:3306/dbname"
slick.dbs.read.db.poolName = "read"
slick.dbs.read.db.registerMbeans = true

slick.dbs.write.driver = "slick.driver.MySQLDriver$"
slick.dbs.read.db.driver = "com.mysql.jdbc.Driver"
slick.dbs.read.db.url = "jdbc:mysql://localhost:3306/dbname"
slick.dbs.read.db.poolName = "write"
slick.dbs.read.db.registerMbeans = true

And relevant parts of the HikariCP debug log:

2016-02-10 18:51:03,846 [DEBUG] com.zaxxer.hikari.HikariConfig - HikariCP pool db configuration:
...
2016-02-10 18:51:03,859 [DEBUG] com.zaxxer.hikari.HikariConfig - poolName........................db
2016-02-10 18:51:03,859 [DEBUG] com.zaxxer.hikari.HikariConfig - readOnly........................false
2016-02-10 18:51:03,859 [DEBUG] com.zaxxer.hikari.HikariConfig - registerMbeans..................true
...
2016-02-10 18:51:03,862 [INFO] com.zaxxer.hikari.HikariDataSource - HikariCP pool db is starting.
2016-02-10 18:51:03,912 [DEBUG] com.zaxxer.hikari.HikariConfig - HikariCP pool db configuration:
...
2016-02-10 18:51:03,921 [DEBUG] com.zaxxer.hikari.HikariConfig - poolName........................db
2016-02-10 18:51:03,921 [DEBUG] com.zaxxer.hikari.HikariConfig - readOnly........................false
2016-02-10 18:51:03,921 [DEBUG] com.zaxxer.hikari.HikariConfig - registerMbeans..................true
...
2016-02-10 18:51:03,922 [INFO] com.zaxxer.hikari.HikariDataSource - HikariCP pool db is starting.
2016-02-10 18:51:03,923 [ERROR] com.zaxxer.hikari.pool.HikariMBeanElf - You cannot use the same pool name for separate pool instances.

[dotta]

@balagez Thanks for the pointer. If I'm understanding things correctly, we should document this problem and suggest to declare the slick.dbs.<db-name>.db.poolName as a workaround until a Slick release that contains the fix is available.

[balagez]

@dotta Unfortunately there's no workaround for end users because due to that bug I mentioned Slick currently doesn't read poolName from configuration but blindly uses the config path as the pool name, which in case of play-slick is always db since play-slick calls DatabaseConfig.forConfig with path = "" and Slick appends the constant db suffix. But simply changing path doesn't work either because then Slick won't find the configuration as the contents of config and the config path get out of sync.

The only opportunity for a workaround I see is rather clumsy, that is to call DatabaseConfig.forConfig with an artificially "padded" config object where all keys in that config are prefixed with the <db-name> and then setting path to <db-name> too. And I'm not at all sure that com.typesafe.config.Config provides a way to prefix all keys so this might not even be a viable option.

In the meantime I patched Slick so the fix is coming in Slick 3.2.0. It's up to you whether you want to implement such a clumsy workaround or just wait for the next Slick release. In the latter case I'm okay with closing this issue, and maybe the documentation could mention that currently it's impossible to implement JMX monitoring of HikariCP pools with play-slick/Slick 3.1.0.

[marcospereira]

Related to #344.

@balagez, your patch is part of slick 3.2.0-RC1 version which is being used by play-slick. So I'm closing this.