Does anyone know the recommended approach for configuring a thread-safe, pooled HTTP client within the Genesys Cloud Java Platform SDK?
I am refactoring our legacy CI/CD automation scripts to use the official Java SDK instead of raw REST calls. The current implementation instantiates a new ApiClient for every concurrent worker thread, which is causing significant overhead and occasional ConnectionPool exhaustion errors during high-volume bulk operations (e.g., updating thousands of user proficiencies simultaneously).
The Java SDK documentation mentions that the underlying HTTP client is an OkHttpClient, but the ApiClient class does not expose a direct setter for a pre-configured client instance. I have attempted to subclass ApiClient to override the initialization logic, but this feels fragile and prone to breaking with SDK updates.
Here is the pattern I am currently using:
// Current approach - creates new client per thread
ApiClient apiClient = new ApiClient();
apiClient.setBasePath("https://api.mypurecloud.com");
apiClient.setAccessToken(token);
UsersApi usersApi = new UsersApi(apiClient);
When scaling this to 50+ concurrent threads, I start seeing intermittent failures that look like this:
java.net.SocketException: Connection reset
at okio.Okio$4.newTimeoutException(Okio.java:232)
Caused by: java.net.SocketException: Connection reset by peer
I suspect this is due to each thread attempting to manage its own connection pool rather than sharing a global pool. I need a way to inject a singleton OkHttpClient with a configured ConnectionPool (e.g., maxIdleConnections=200, keepAlive=5 minutes) into the UsersApi or RoutingApi instances without modifying the SDK source code.
Is there a supported factory method or constructor in the Java SDK that accepts a custom OkHttpClient? If not, what is the most robust workaround for managing connection pooling in a multi-threaded Python-to-Java migration scenario?