CXone Java SDK 1.2.4 Thread Safety and Connection Pooling

Running CXone Java SDK 1.2.4 in a multi-threaded batch job. Creating a single PlatformClient instance per thread causes massive resource exhaustion. The docs are vague on connection pooling. Is the underlying HttpClient truly thread-safe for concurrent requests from a single PlatformClient instance?

We have a legacy integration that processes 500 records per second. Currently, the code instantiates a new PlatformClient for each worker thread. This blows up the thread pool and triggers OOM errors within minutes.

Here is the current pattern:

public void processRecord(String id) {
 PlatformClient client = PlatformClientFactory.createClient(clientId, clientSecret, defaultRegion);
 // call analytics api
 client.getAnalyticsApi().getConversationAnalytics(...);
}

I tried moving the client creation to a static singleton. That seemed to work for a while. Then we hit intermittent 502 Bad Gateway errors from the NICE edge. The stack trace points to connection pool exhaustion inside the SDK’s internal RestConnector.

I dug into the SDK source. It uses Apache HttpClient 4.5.x. The default connection manager is not thread-safe. The SDK doesn’t seem to expose a way to inject a PoolingHttpClientConnectionManager.

So I’m stuck.

Option A: Keep one client per thread. Accept the overhead. It’s stable but slow and memory-heavy.
Option B: Use a single shared client. Risk 502s and connection timeouts under load.
Option C: Write a custom wrapper that manages its own HttpClient instance and bypasses the SDK’s RestConnector. This feels fragile. Updates to the SDK might break the internal APIs.

Has anyone successfully tuned the connection pool size? I see a setConnectionTimeout method on the PlatformClient. Is there a setMaxConnections equivalent?

The official docs say the client is “stateless”. That usually implies thread safety. But the underlying HTTP connections are stateful.

We are running on AWS EC2. CPU is fine. Memory is the bottleneck.

Looking for a concrete example of a thread-safe configuration. Or confirmation that the SDK simply doesn’t support high concurrency out of the box.

Thanks.