I’m refactoring our custom agent desktop widget to handle bulk screen pop data fetching when a multi-party interaction comes in. We’re using the Java Platform SDK (v4.9.0) and noticed that under heavy load, the HTTP client seems to hang or throw timeout exceptions. I suspect the default connection pooling configuration isn’t thread-safe enough for what we’re doing.
Here is the setup. I’m initializing the API client like this:
ApiClient apiClient = ApiClientBuilder.standard()
.setBasePath("https://api.mypurecloud.com")
.setAccessToken("<token>")
.build();
RoutingApi routingApi = new RoutingApi(apiClient);
When a call comes in, I spin up 5 threads to fetch different data points (customer profile, queue status, previous interactions) concurrently. Each thread calls routingApi.getInteractionsInteraction(...). After about 50 requests, I start seeing java.net.SocketTimeoutException and ConnectionPoolTimeoutException.
I tried adjusting the pool size manually by accessing the underlying OkHttp client, but the SDK abstracts that away. I found a reference to ApiClient.setHttpClient() but I’m not sure how to configure the ConnectionPool correctly without breaking the SDK’s internal logic.
// Attempted fix that didn't work well
OkHttpClient okClient = new OkHttpClient.Builder()
.connectionPool(new ConnectionPool(100, 5, TimeUnit.MINUTES))
.build();
apiClient.setHttpClient(okClient);
The issue is that the SDK seems to override some settings or the pool isn’t being shared properly across the threads spawned by my widget. Is there a recommended way to configure a shared, thread-safe HTTP client for the Java SDK? I need to make sure I’m not creating a new connection for every API call, but also not blocking the UI thread.
I’ve checked the docs but they don’t mention concurrency limits. We’re on the west coast cluster. Any ideas on how to tune this?