Java SDK connection pooling and thread-safe HTTP client configuration

General Discussion
1

Problem
Java SDK client is dropping connections under load. We’re spinning up a batch processor. Thread safety seems off. Docs mention Apache HttpClient but no examples. We can’t find the setter.

Code

PlatformClient client = new PlatformClient.Builder()
 .withClientId("x")
 .withClientSecret("y")
 .build();

Error
java.net.SocketTimeoutException: Read timed out. Pool isn’t recycling.

Question
How do we configure the underlying HTTP client for pooling?

2

The default builder in the Java SDK uses a basic HttpClient that doesn’t pool connections aggressively enough for high-throughput batch jobs. You need to inject your own Client implementation or configure the underlying Apache HttpClient before building the platform client.

The docs for PlatformClient.Builder mention .withRestClient(Client client) but don’t show how to wire up the pool. Here is how I did it in C# using HttpClientHandler, and the Java equivalent is very similar using PoolingHttpClientConnectionManager.

In Java, you have to create the connection manager first:

PoolingHttpClientConnectionManager connManager = new PoolingHttpClientConnectionManager();
connManager.setMaxTotal(200);
connManager.setDefaultMaxPerRoute(50);

CloseableHttpClient httpClient = HttpClients.custom()
 .setConnectionManager(connManager)
 .setDefaultRequestConfig(RequestConfig.custom()
 .setConnectTimeout(5000)
 .setSocketTimeout(15000)
 .build())
 .build();

// Wrap it in the SDK's Client interface or use the builder that accepts a CloseableHttpClient if available in your version
// Note: PureCloudPlatformClientV2 sometimes exposes .withHttpClient() in newer versions
PlatformClient client = new PlatformClient.Builder()
 .withClientId("x")
 .withClientSecret("y")
 .withHttpClient(httpClient) // Check your SDK version for this method
 .build();

If your SDK version doesn’t expose .withHttpClient(), you might have to dig into PureCloudPlatformClientV2 internals or use the lower-level ApiClient class which gives you direct control over the Client.

Also check if you are reusing the PlatformClient instance. Creating a new client per thread kills the pool benefits. The client itself is thread-safe for API calls, so share one instance across your batch processor.

One thing to watch out for is the timeout settings. Genesys Cloud can be slow with large report queries. If you set socket timeout too low, you’ll get Read timed out even with pooling.

I ran into this last month with an Azure Function calling GC APIs. Switching to a pooled client fixed the 504s.