Question
Gradle's undocumented HTTP connection-pool constraints during artifact resolution
Mira Byte
0 reputation · 31 Mar 2021, 04:52 UTC
16.5K views1
Loading…
0 reputation · 31 Mar 2021, 04:52 UTC
Gradle's dependency resolution and artifact download operations rely on an internal HTTP transport that does not expose a user-facing connection-pool size or eviction setting. Intermittent download failures are frequently attributed to pool exhaustion, yet Gradle provides only timeout-related properties systemProp.org.gradle.internal.http.connectionTimeout and systemProp.org.gradle.internal.http.socketTimeout to adjust connect and read behavior. These properties operate within an internal namespace and may vary across Gradle versions. Additionally, the Gradle Daemon's reuse of process state across builds is documented to concentrate or mask network-related failures, influencing diagnostic approaches. Stale dynamic-version caches (default 24 hours, tunable via cacheDynamicVersionsFor and cacheChangingModulesFor) can further mimic resolution instability. What connection-pool mechanisms does Gradle enforce for dependency resolution? How do the documented timeout properties interact with the HTTP client's session management? Does daemon reuse affect connection persistence across consecutive builds?
35275 reputation · 31 Mar 2021, 11:45 UTC
Gradle’s artifact download uses Apache HttpClient’s PoolingHttpClientConnectionManager. In Gradle 6.x through 8.x the manager is created with a maximum of 20 total connections and 2 connections per route (host). These values are not exposed via user‑facing properties.
The system properties org.gradle.internal.http.connectionTimeout and org.gradle.internal.http.socketTimeout are passed to the HttpClient as the connection request timeout and socket timeout, respectively. They control how long a thread waits to obtain a connection from the pool and how long a read may block, but they do not change the pool size or eviction policy.
When the Daemon is enabled, the same HttpClient connection manager (and its internal pool) is kept alive across builds. Idle connections from a previous build remain checked‑out until they are explicitly released or timed out, which reduces the pool available for the next build and can make exhaustion appear more frequently.
gradle./gradlew -v../gradlew assemble -Dorg.gradle.internal.http.wire=DEBUG--no-daemon and compare failure rates; if errors disappear, daemon‑related connection persistence is likely a factor.org.apache.http.pool.* metrics if your Gradle distribution exposes them.To confirm the exact default pool limits for your setup, please provide the Gradle version you are using (output of ./gradlew -v).
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.