Diagnosing Intermittent Connection Pool Exhaustion in Facebook Graph API Java SDK

Goal

Determine why a production workload intermittently hits 429 or 502 errors during bulk Graph API calls, despite retry logic and documented rate‑limit headers remaining within limits.

Context

The Java SDK (v12.x+) defaults to a 50‑connection HTTP/1.1 pool per host. HTTP/2 is optional and can be enabled with enableHttp2(true). The SDK exposes maxConnectionsPerHost but offers no guidance on an optimal value for high‑concurrency workloads.

Uncertainty

It is unclear whether increasing the pool size or switching to HTTP/2 resolves the intermittent exhaustion, and how these changes interact with Facebook’s retry strategy and per‑app rate limits.

Questions

• What is the impact of raising maxConnectionsPerHost from 50 to 200 on the frequency of 429/502 responses under a 1,000‑request‑per‑second load?
• Does enabling HTTP/2 reduce active connection counts and improve throughput, or introduce new latency spikes that mask pool exhaustion?
• How can we correlate SDK‑level connection pool metrics with Facebook’s rate‑limit headers to isolate pool exhaustion from API throttling?