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

Create new connection provider during IP failovers #117

Conversation

aegbert5
Copy link
Contributor

@aegbert5 aegbert5 commented Nov 7, 2024

No description provided.

@aegbert5 aegbert5 force-pushed the create-new-connection-provider-during-failovers branch 2 times, most recently from 75da1bb to 43ce57b Compare November 7, 2024 02:37
@aegbert5 aegbert5 force-pushed the create-new-connection-provider-during-failovers branch from 43ce57b to ea0a360 Compare November 7, 2024 02:46
@@ -111,7 +112,28 @@ class ConnectionProvider(props: Properties) {
val newIP: String = getIP
if (hasIpAddressChanged(pool, newIP)) {
// A failover has occurred, so we evict connections softly. New connectons look up the new IP address
pool.connectionProvider.map(_.getDataSource().getHikariPoolMXBean().softEvictConnections())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a theory that softEvictConnections() does not permit future connections be opened within the same pool. Creating a new HikariPool from scratch will guarantee to use the new IP address returned from the CNAME URL

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly we are running into brettwooldridge/HikariCP#1836 ?

I have a theory that softEvictConnections() does not permit future connections be opened within the same pool.

I don't thilnk that is right. Nothing in the documentation indicates that behavior.

However, brettwooldridge/HikariCP#228 does recommend replacing the entire pool, so I guess that might be a better approach.

@@ -34,7 +34,8 @@ class ConnectionProvider(props: Properties) {
@volatile
private var cachedIpWithExpiration: Option[CachedIpWithExpiration] = None

private val pool: Pool = new Pool(getIP)
@volatile
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unnecessary since we only access it from within a synchronized block.

Copy link
Contributor Author

@aegbert5 aegbert5 Nov 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We read from this value outside the synchronized block on lines 113, 115, and 139, for example to get a connection:

pool.connectionProvider.get.getConnection

Thus volatile will make sure the pool is assigned completely before we attempt to get connections from it

@tmccombs tmccombs merged commit 785cf65 into lucidsoftware:master Nov 7, 2024
1 check passed
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

Successfully merging this pull request may close these issues.

3 participants