Cached HBase connection eviction vs. Phoenix Query Server centralization: trading pool controllability for latency under intermittent exhaustion

Intermittent connection pool exhaustion in Phoenix often stems from ambiguous root causes when cached HBase connections are shared across the JDBC client pool.

The documented thick driver caches a single HBase Connection per client configuration, and closing the JDBC connection does not guarantee release of region-server resources; eviction is governed by HBase's idle-timeout clock, which unrelated background activity can reset, making eviction timing nondeterministic from the client side.

Under what HBase idle-timeout configuration does cached-connection eviction become deterministic from the client side? Does migrating to the thin driver via Phoenix Query Server eliminate per-client exhaustion or relocate pool saturation to the query-server tier? For a deployed Phoenix release, which metrics reliably distinguish exhaustion originating in cached HBase connections from that in the query-server pool?