terrymanu commented on issue #37745:
URL:
https://github.com/apache/shardingsphere/issues/37745#issuecomment-3763245622
Core view: this most likely matches Hikari’s normal behavior (connections
not returned, so the pool can’t reap by idleTimeout), but processlist alone
can’t rule out an implementation issue, so we need pool-side data to confirm.
Issue Understanding
- ShardingSphere-JDBC 5.3.2 + Hikari; idleTimeout and other pool props
set; after the load test ends, MySQL still shows ~38 connections.
Root Cause
- In 5.3.2, ShardingSphere maps idleTimeout/maximumPoolSize/minimumIdle
and applies them via Hikari setters; misapplied config is unlikely.
- Hikari only reaps connections that are returned and above minimumIdle;
if connections stay open or in a transaction, the pool sees them as active and
won’t shrink—this matches Hikari design.
Analysis
- processlist shows MySQL-side connections, but doesn’t tell whether
Hikari sees them as active or idle.
- If Hikari stats show Active > 0 or Idle ≈ Total, it’s unreturned
connections/long transactions; if Idle ≫ minimumIdle and still not reaped,
config might be ineffective or there’s a bug.
Conclusion (need info to finalize)
- No sufficient evidence of a ShardingSphere bug; more likely connections
aren’t being returned, preventing shrink. Please share:
1. Startup Hikari configuration log (HikariPool-... configuration)
showing effective idleTimeout/minimumIdle/maximumPoolSize.
2. Hikari PoolStats or JMX/Micrometer metrics after the load stops
(Active/Idle/Total).
3. A few sample processlist rows for the lingering connections
(Command/Time).
4. How connections are acquired/closed (framework version, transaction
settings, any manual Connection/Statement handling).
--
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]
