-
Notifications
You must be signed in to change notification settings - Fork 55
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
Provide a way to do scheduled connection validation #187
Comments
Yes, it seems to be a problem for me as well. I implemented it in my program, and I hope there |
Background validation would require taking the connection from the pool, testing it, and putting it back to ensure that the pool doesn't use it concurrently and another process that allocates the connection. In any case, that kind of functionality would be required to be provided by Reactor Pool. Feel free to file a ticket at https://github.com/reactor/reactor-pool/issues |
Issue was created at reactor/reactor-pool#169 |
@mp911de reactor/reactor-pool#169 (comment) is this functionality provided by reactor-pool sufficient? |
Connection is removed if invalid when getting from the pool. How did this happen? Any help would be appreciated. |
@grantas33 the comment refers to warmup, not scheduled validations. For scheduled validation, we would need to have a scheduler and a task to allocate/de-allocate a connection from the pool. When we do this from the outside, then we have to follow the pool order and therefore, we cannot guarantee that we've verified every connection. That being said, we require support for scheduled validation in Reactor Pool first. |
Feature Request
Is your feature request related to a problem? Please describe
Idle connections can become invalid due to timeouts on the database or the network side or other causes. In such case, when performing a database call we potentially would have to retry the acquirement of the whole pool size of connections and re-warmup the pool if no valid connections exist. This adds a substantial amount of time to the database call, which could have been avoided if the connection validation was periodically run in the background.
Describe the solution you'd like
The implementation behind
backgroundEvictionInterval
configuration parameter could be extended. Instead of checking for each connection if it has exceeded itsmaxIdleTime
, it would also check for each connection if it is valid. Also, after the checks, the connection pool should be re-warmuped, so that it contains at leastminIdle
connections.This feature exists in popular JDBC pool libraries like HikariCP (
keepaliveTime
) and C3P0 (idleConnectionTestPeriod
) and the lack of scheduled validation could be a problem when migrating to r2dbc-poolThe text was updated successfully, but these errors were encountered: