Can I Expose Selenium’s HttpClient Connection Pool Size for Parallel Test Execution?

Answer

No. Selenium 4.15 does not expose the Apache HttpClient connection pool size for RemoteWebDriver through a public API, WebDriver capability, or documented system property. The maxConnectionsPerRoute value is not user configurable in the released 4.15 artifacts.

Confirmed facts

• RemoteWebDriver creates its Apache HttpClient internally via Selenium's HttpClientFactory.
• The factory instantiates a PoolingHttpClientConnectionManager with a hard-coded per-route limit. There is no public setter, capability, or documented system property to change it in 4.15.
• Modifying Selenium source is undesirable and the internal implementation is version-sensitive and may change in future releases.

Likely explanation for ConnectionPoolTimeoutException

With more than ten concurrent RemoteWebDriver instances targeting the same Selenium Grid hub or node host, the small internal per-route pool is exhausted. Requests wait for a free connection and eventually throw ConnectionPoolTimeoutException. This is an internal implementation detail, not a configurable client limit.

Workaround steps for this case

1. Limit concurrency per JVM/process. Keep concurrent RemoteWebDriver instances per process at or below the effective per-route capacity to avoid pool exhaustion.
2. Reuse drivers. Use a driver pool or session reuse pattern instead of creating a new RemoteWebDriver for every test.
3. Spread routes. Fan out tests across multiple Grid nodes or distinct hub hostnames so connections are distributed across routes. Each unique host:port gets its own pool.
4. Match server capacity. Ensure the Selenium Grid node can accept the increased parallel connections and that server-side connection limits are not the new bottleneck.

Providing a custom HttpClient.Factory via internal extension points is technically possible but undocumented, version-sensitive, and unsupported in 4.15. It is not recommended for production test stability.

One diagnostic detail that changes the recommendation

Do all concurrent RemoteWebDriver instances target the same hub/node host and port? If yes, route spreading or parallelism reduction is required. If they already target different hosts, the pool limit is less likely to be the root cause and investigation should shift to node resources or network limits.