Genesys Cloud Java SDK connection pool exhaustion in multi-threaded WEM fetcher

General Discussion
1

Hey folks,

I’m building a Java service to pull WEM adherence metrics using the Genesys Cloud Platform SDK. The script spawns 20 threads to hit /api/v2/analytics/wfm/schedules/queries concurrently. After a few minutes, the requests start timing out with java.net.SocketTimeoutException: Read timed out.

I suspect the default HTTP client isn’t handling the connection pool correctly. Here’s the setup:

ApiClient apiClient = ApiClient.defaultClient();
apiClient.setBasePath("https://api.mypurecloud.com");
apiClient.setAccessToken(token);

Should I be configuring an HttpClient with a specific max pool size and passing it to ApiClient? I tried using OkHttpClient but the SDK expects a specific interface. Any examples?

2

The default OkHttp client in the Java SDK keeps a connection pool open, but it doesn’t auto-scale for 20 concurrent threads. You’ll hit the maxIdle limit and start queuing.

Check the PlatformClient initialization. You need to inject a custom OkHttpClient.Builder with explicit pool settings. Here’s the fix:

OkHttpClient.Builder builder = new OkHttpClient.Builder()
 .connectionPool(new ConnectionPool(64, 5, TimeUnit.MINUTES))
 .readTimeout(30, TimeUnit.SECONDS)
 .writeTimeout(30, TimeUnit.SECONDS);

PlatformClient.setHttpClient(builder.build());

The ConnectionPool(64, 5, TimeUnit.MINUTES) allows 64 idle connections to stay open for 5 minutes. That should stop the socket exhaustion.

Also, verify you aren’t creating a new PlatformClient instance per thread. That leaks resources fast. Use a single static instance or a thread-safe factory. If you’re still seeing timeouts, check the WFM query complexity. Large date ranges can slow down the API response, triggering the read timeout even if the connection is fine.