You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Thomas Meyer <th...@m3y3r.de> on 2023/01/17 18:33:07 UTC

Tomcat JDBC CP: Exponential backoff?

Hi,

Does Tomcat's CP support exponential backoff in case DB is unavailable for some reason?
I didn't find anything in the documentation in this regards.

Mfg
Thomas


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Tomcat JDBC CP: Exponential backoff?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
Thomas,

On 1/26/23 03:00, Thomas Meyer wrote:
> 
> 
> Am 18. Januar 2023 23:20:29 MEZ schrieb Christopher Schultz <ch...@christopherschultz.net>:
>> Thomas,
>>
>> On 1/17/23 13:33, Thomas Meyer wrote:
>>> Does Tomcat's CP support exponential backoff in case DB is unavailable for some reason?
>>> I didn't find anything in the documentation in this regards.
>>
>> I don't think is supports any such thing. What would be the purpose of exponential back-off... don't you want to connect ASAP?
> 
> Hi,
> 
> Not really sure, but I think the idea is to protect the database from getting overloaded with requests once it's coming up again.
> 
> Sadly the description given in
> https://cloud.google.com/sql/docs/postgres/manage-connections#backoff
> 
> Is very vague and I think won't really help much to mitigate above problem, if any.
> 
> I found this interesting article and test class that tries to demonstrate the resp. behavior of the situation:
> https://github.com/brettwooldridge/HikariCP/wiki/Bad-Behavior:-Handling-Database-Down
> https://github.com/brettwooldridge/HikariCP-benchmark/blob/master/src/test/java/com/zaxxer/hikari/benchmark/DbDownTest.java
> 
> There seems also to be an reply to above benchmark from the vibur dbcp author, which has some interesting points:
> https://github.com/brettwooldridge/HikariCP/issues/230
> 
> While investigating the reason of why exponential backoff would make sense I also did stumble across this article:
> https://aws.amazon.com/de/blogs/architecture/exponential-backoff-and-jitter/
> 
> This article make much more sense in my head, I.e. use exponential backoff with jitter to protect the restarting database from getting "flooded".
> 
> But HikariCP does only support plain exponential backoff and probably won't help much in above described situation, because once the database is starting to accept connections again, all HikariCP connections will probably align at the same time to start creating connections again.

If you are worried abou tyour database being flooded with requests, you 
should limit the number of connections your database will accept /at the 
database/.

If you have 10 applications connecting to the db each with their own 
connection pools, even exponential backoff won't help avoid all of them 
(separately!) flooding the database.

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Tomcat JDBC CP: Exponential backoff?

Posted by Thomas Meyer <th...@m3y3r.de>.

Am 18. Januar 2023 23:20:29 MEZ schrieb Christopher Schultz <ch...@christopherschultz.net>:
>Thomas,
>
>On 1/17/23 13:33, Thomas Meyer wrote:
>> Does Tomcat's CP support exponential backoff in case DB is unavailable for some reason?
>> I didn't find anything in the documentation in this regards.
>
>I don't think is supports any such thing. What would be the purpose of exponential back-off... don't you want to connect ASAP?

Hi,

Not really sure, but I think the idea is to protect the database from getting overloaded with requests once it's coming up again.

Sadly the description given in
https://cloud.google.com/sql/docs/postgres/manage-connections#backoff

Is very vague and I think won't really help much to mitigate above problem, if any.

I found this interesting article and test class that tries to demonstrate the resp. behavior of the situation:
https://github.com/brettwooldridge/HikariCP/wiki/Bad-Behavior:-Handling-Database-Down
https://github.com/brettwooldridge/HikariCP-benchmark/blob/master/src/test/java/com/zaxxer/hikari/benchmark/DbDownTest.java

There seems also to be an reply to above benchmark from the vibur dbcp author, which has some interesting points:
https://github.com/brettwooldridge/HikariCP/issues/230

While investigating the reason of why exponential backoff would make sense I also did stumble across this article:
https://aws.amazon.com/de/blogs/architecture/exponential-backoff-and-jitter/

This article make much more sense in my head, I.e. use exponential backoff with jitter to protect the restarting database from getting "flooded".

But HikariCP does only support plain exponential backoff and probably won't help much in above described situation, because once the database is starting to accept connections again, all HikariCP connections will probably align at the same time to start creating connections again.

>
>-chris
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Tomcat JDBC CP: Exponential backoff?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
Thomas,

On 1/17/23 13:33, Thomas Meyer wrote:
> Does Tomcat's CP support exponential backoff in case DB is unavailable for some reason?
> I didn't find anything in the documentation in this regards.

I don't think is supports any such thing. What would be the purpose of 
exponential back-off... don't you want to connect ASAP?

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org