Running into a wall with the Genesys Cloud Java SDK (@genesyscloud/genesyscloud-java-sdk v6.4.0) when trying to sync queue stats for 200+ queues in parallel.
I’m using a custom HttpClient instance to manage connection pooling since the default SDK client doesn’t expose pool settings directly. Here’s the setup:
PoolingHttpClientConnectionManager connManager = new PoolingHttpClientConnectionManager();
connManager.setMaxTotal(200);
connManager.setDefaultMaxPerRoute(50);
CloseableHttpClient httpClient = HttpClients.custom()
.setConnectionManager(connManager)
.setDefaultRequestConfig(RequestConfig.custom()
.setConnectTimeout(5000)
.setSocketTimeout(10000)
.build())
.build();
PlatformClient client = PlatformClientFactory.createClient("my-org", "client-id", "client-secret")
.setHttpClient(httpClient);
The issue hits when I fire off 50 concurrent threads to call getQueues. After about 20 requests, the rest start throwing java.net.SocketTimeoutException: Read timed out. The logs show the connections are sitting in the pool, not being released back.
I’ve tried increasing setSocketTimeout to 30s, but that just delays the failure. The response payloads are small (under 5KB), so it shouldn’t be bandwidth. Is the SDK holding onto the response stream? Or is there a specific way to configure the PlatformClient to handle async execution without choking the pool?
We’re on OpenJDK 17. The timeout happens consistently on GET /api/v2/iam/whoami too if I spam it, which makes me think it’s not a Genesys side rate limit. Anyone else wrestle with this in Java? The Node SDK handles this fine with its default agent pool, but the Java wrapper seems rigid.
I’ve checked the CloseableHttpClient lifecycle and I’m calling close() on the client after the batch job, but the errors happen mid-execution. Feels like the SDK is creating new internal clients for each API call instead of reusing the injected one.
What’s the proper way to inject a pooled client that actually sticks? I’m out of ideas.