Running into thread starvation with the Genesys Cloud Java Platform SDK (v2.28.1). We’re pushing about 50 concurrent API calls per second from a single service instance to update interaction metadata. The application starts fine, but after a few minutes, threads block indefinitely on HttpClient.execute. The stack trace points to java.util.concurrent.locks.ReentrantLock inside the Apache HttpClient connection pool. No HTTP errors are returned initially. It just hangs.
I assumed the SDK would handle pooling automatically. The default configuration seems to use a basic PoolingHttpClientConnectionManager. I tried overriding the HTTP client factory in the GenesysClient builder. Here’s the setup I’m using:
ConnectionRequestTimeout connectionRequestTimeout = ConnectionRequestTimeout.custom(5000, TimeUnit.MILLISECONDS);
PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
connectionManager.setMaxTotal(200);
connectionManager.setDefaultMaxPerRoute(50);
HttpClient httpClient = HttpClientBuilder.create()
.setConnectionManager(connectionManager)
.setDefaultRequestConfig(RequestConfig.custom()
.setConnectTimeout(5000)
.setSocketTimeout(10000)
.build())
.build();
GenesysClient client = GenesysClient.builder()
.withHttpClient(httpClient)
.withAuthFlow(authFlow)
.build();
The pool size hits 200 quickly. Requests queue up. I increased setMaxTotal to 500, but it didn’t help much. The connections seem to be held open longer than expected. Are there specific timeouts I need to set on the GenesysClient side to force idle connection eviction? Or is the issue with how the SDK manages the underlying CloseableHttpClient lifecycle? I noticed the SDK docs don’t mention thread-safe configuration for high-throughput scenarios.
Also, is it safe to share a single GenesysClient instance across multiple threads? The docs imply yes, but the blocking behavior suggests otherwise. I’ve tried creating a new client per thread, which works but adds overhead. Looking for a way to configure the pool properly. Any insights on tuning the connection manager for this SDK?