Intermittent Database Inspector connection failures — Android Studio
0 reputation · 10 Nov 2020, 23:03 UTC
The goal is to attribute repeated Database Inspector connection failures to one of three layers: the inspected application or its embedded database, the inspection connection path, or a saturated backend connection pool.
Android Studio Database Inspector inspects supported application databases and runs SQL against them, but it does not own the connection pool. Pool limits, wait behavior, and acquisition timeouts depend on the database and client driver, and exact tooling can change between Android Studio releases. A generic connection failure is therefore not sufficient evidence of pool exhaustion; supporting evidence such as connection waits, acquisition timeouts, or server-side saturation at matching timestamps is required.
Assuming a pinned Android Studio version and a pinned database/driver version, what distinguishes a target-discovery failure from a connection-establishment failure versus a query-execution failure in Database Inspector? Which server-side pool metrics or logs should be compared against Inspector failure timestamps to confirm or reject pool exhaustion? Does reproducing the failure with a second client using equivalent credentials and driver settings isolate the Inspector path from the backend pool?