When creating physical connections, catch throwable instead of exception #2300
+8
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Although rare, JDBC drivers can and do throw java.lang.Error instead of java.lang.Exception under certain conditions. If this occurs, the Error is swallowed since it is not currently caught and it occurs on a separate thread where the result is never checked.
If the driver continues to throw Error, the backoff logic is bypassed, the connection creation counter spikes and eventually the pool drains of all connections.
See example
Graph of connection creation counter

Graph of connections for the pool

The trigger was a networking event. At this time, we don't know with absolute certainty that the driver was generating an Error. However, after reviewing the code, I could not determine another explanation. The backoff logic clearly was not being hit as the counter would not increase and stay at the rate. We put out a patched version of Hikari similar to the changes in this PR with hopes of confirming that is what is happening and collecting the actual error being thrown, but we are waiting for the situation to occur again.
In this case we are using oracle's jdbc driver, and we have seen it throw a java.lang.Error before in other situations.
If this change is of interest and you want an explicit test for this, I'm happy to do that, but I may need a little direction on preferences here.