fivetran-ashokborra commented on code in PR #3566:
URL: https://github.com/apache/polaris/pull/3566#discussion_r2746355416
##########
persistence/relational-jdbc/src/main/java/org/apache/polaris/persistence/relational/jdbc/DatasourceOperations.java:
##########
@@ -312,7 +312,8 @@ private boolean isRetryable(SQLException e) {
// Additionally, one might check for specific error messages or other
conditions
return e.getMessage().toLowerCase(Locale.ROOT).contains("connection
refused")
- || e.getMessage().toLowerCase(Locale.ROOT).contains("connection
reset");
+ || e.getMessage().toLowerCase(Locale.ROOT).contains("connection reset")
+ || e.getMessage().toLowerCase(Locale.ROOT).contains("acquisition
timeout");
Review Comment:
That's a fair point @adutra. Retry seems like an anti-pattern from a queue
fairness perspective. I made the changes from a resiliency perspective; having
a retry might ensure a connection rather than a short timeout failure.
@dimas-b, Yes, retry would add some overhead. If the connection pool is
saturated for a prolonged period, a longer timeout would result in more threads
piling up in memory.
Maybe we are trying to solve the wrong problem with these changes rather
than adjusting the max pool size. Nevertheless, this situation can happen.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
