Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Developer experience: allow configuring HikariCP with java.time.Duration instead of millisecond / second parameters #2191

Open
hiddewie opened this issue Apr 8, 2024 · 0 comments

Comments

@hiddewie
Copy link

hiddewie commented Apr 8, 2024

Currently, configuring the idleTimeout property of the connection pool will use the setIdleTimeout method on the HikariConfig configuration class.

Similarly, many of the other configuration parameters are duration values. The values range from millisecond, to second, to minute. This difference in order of magnitude can make it error-prone to configure the connection pool correctly, and review the configured values.

It would be great to be able to configure the connection pool using java.time.Duration values, for example

configuration.setIdleTimeout(Duration.ofMinutes(5))
configuration.setIdleTimeout(Duration.ofSeconds(10))

This makes the intent clear of the code more clear than the current

configuration.setIdleTimeout(300000)
configuration.setIdleTimeout(5 * 60 * 1000)
configuration.setIdleTimeout(10000) // 10 seconds, or did I make a typo got a zero too much or too little?

I am willing to build a pull request if this feature is found to be useful.

Implementation seems to be extending the HikariConfigMXBean with extra setter methods, and extending the implementation HikariConfig.

Furthermore, PropertyElf could be extended to take into account property values of the same syntax, for example:

# 5 minutes idle timeout, all properties are equivalent
idleTimeout = 300000 
idleTimeout = 300s
idleTimeout = 5m
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant