HikariCP behavior when no connection is available

Question

I noticed that even when the database is down, so no connection is actually available in the pool, Hikari CP still waits for the connection timeout to expire before sending an exception to the client.

I agree this is desirable when the database is available, but in my case I would like for the pool not to wait before sending an exception when no connection is available.

The reason is that the database itself answers in less than 2ms , so I can handle thousands of transactions per second but when there is no connection available the pool will wait for a lot longer (the minimum acceptable timeout recommended being 250 ms) so I can no longer handle the throughput. On the other hand, my logic can work without the database for a period of time.

How should I manage this?

EDIT:

This link is almost what I want to achieve, minus the fact that I would prefer HikariCP to do this automatically, I shouldn't activate the suspend state.

Answer 1

Perhaps you should introduce a counter somewhere in your application code and if the number of concurrent requests exceeds the value don't use database. It's hard to tell without knowing what you are dealing with eg read vs write.

As per brettwooldridge comment regarding connectionTimeout property lower timeout is unreliable due to thread scheduling, even when there are available connections:

We can certainly consider a lower floor, but 125ms would be the absolute minimum.

Both Windows and Linux have a default scheduler quantum of 20ms. If 16 threads are running on a 4-core CPU, a single thread may have to wait up to 80ms just to be allowed to run. If the pool has a vacancy due to, for example, the retirement of a connection at maxLifetime, this leaves precious little time to establish a connection to fill the slot without returning a spurious failure to the client.

If careful consideration is not taken to ensure the CPU and scheduler are not oversaturated, running at a 125ms timeout, puts your application tier at risk of spurious failures even if the pool has available connections. For example, running 32 threads on a 4-core CPU can lead to thread starvations under load as long as 120ms -- very close to the edge.