Bug Report / Improvement
Is your issue related to a problem? Please describe.
SqlSessionFactoryHelper configures the DBCP2 connection pool with two problematic values:
dataSource.setMinIdle(0); // pool can shrink to zero
dataSource.setMinEvictableIdleTimeMillis(1000); // evict after 1 second idle
The evictor thread runs every 10 minutes (timeBetweenEvictionRunsMillis = 10 min). With minEvictableIdleTimeMillis = 1s, every connection idle for more than 1 second is eligible for eviction. After any quiet period ≥ 10 minutes all connections are evicted, and with minIdle = 0 the pool shrinks to zero.
When traffic resumes, the first N requests must each pay a DB connection-establishment cost (TCP handshake + auth + protocol negotiation — typically 20–100 ms on MySQL/PostgreSQL). Under concurrent load this can cause a burst of connection-creation overhead.
This problem is amplified when the entity store cache is disabled, because every auth request then issues 3+ DB queries, and each query competes for connections from a pool that may be empty.
What value of minEvictableIdleTimeMillis = 1000 is suspicious?
1 second is effectively "evict everything on every evictor run", since the evictor only runs every 10 minutes anyway. This looks like a dev/test value that was committed to production.
Describe the solution you'd like
| Setting |
Current |
Proposed |
Rationale |
minIdle |
0 |
5 |
Always keep 5 warm connections; eliminate cold-start latency after idle periods |
minEvictableIdleTimeMillis |
1000 (1 s) |
30000 (30 s) |
Use Duration.ofSeconds(30).toMillis() for clarity; prevents accidental over-aggressive eviction if the evictor interval is ever shortened |
Additional context
File: core/src/main/java/org/apache/gravitino/storage/relational/session/SqlSessionFactoryHelper.java
These settings are hardcoded (not configurable). The fix is a one-line-each change with no API surface impact.
Bug Report / Improvement
Is your issue related to a problem? Please describe.
SqlSessionFactoryHelperconfigures the DBCP2 connection pool with two problematic values:The evictor thread runs every 10 minutes (
timeBetweenEvictionRunsMillis = 10 min). WithminEvictableIdleTimeMillis = 1s, every connection idle for more than 1 second is eligible for eviction. After any quiet period ≥ 10 minutes all connections are evicted, and withminIdle = 0the pool shrinks to zero.When traffic resumes, the first N requests must each pay a DB connection-establishment cost (TCP handshake + auth + protocol negotiation — typically 20–100 ms on MySQL/PostgreSQL). Under concurrent load this can cause a burst of connection-creation overhead.
This problem is amplified when the entity store cache is disabled, because every auth request then issues 3+ DB queries, and each query competes for connections from a pool that may be empty.
What value of
minEvictableIdleTimeMillis = 1000is suspicious?1 second is effectively "evict everything on every evictor run", since the evictor only runs every 10 minutes anyway. This looks like a dev/test value that was committed to production.
Describe the solution you'd like
minIdle05minEvictableIdleTimeMillis1000(1 s)30000(30 s)Duration.ofSeconds(30).toMillis()for clarity; prevents accidental over-aggressive eviction if the evictor interval is ever shortenedAdditional context
File:
core/src/main/java/org/apache/gravitino/storage/relational/session/SqlSessionFactoryHelper.javaThese settings are hardcoded (not configurable). The fix is a one-line-each change with no API surface impact.