Hey everyone,
We’re running into some weird behavior with the Genesys Cloud Java SDK (version 17.2.0) in our hybrid environment. We have a background service that polls /api/v2/interaction endpoints to sync conversation history to our local DB. It works fine for a few hours, then suddenly every request starts timing out or failing with 503 Service Unavailable.
I’ve been digging into the ApiClient configuration. The default setup seems to use an OkHttpClient under the hood, but I’m not sure how the connection pool is sized by default. Here’s how we’re initializing the client:
ApiClient apiClient = ApiClientBuilder.builder()
.withClientId(config.getGenesysClientId())
.withClientSecret(config.getGenesysClientSecret())
.withBaseUrl(config.getGenesysBaseUrl())
.build();
// We share this single instance across multiple threads via a singleton service
conversationService.setApiClient(apiClient);
The issue is that we spawn 10 threads to parallelize the fetches. When the load spikes, I see logs indicating the connection pool is maxed out. I tried to pass a custom OkHttpClient to the builder, but the withHttpClient method seems to ignore the connectionPool settings I pass in, or maybe I’m doing it wrong.
OkHttpClient customClient = new OkHttpClient.Builder()
.connectionPool(new ConnectionPool(50, 2, TimeUnit.MINUTES))
.build();
ApiClient apiClient = ApiClientBuilder.builder()
.withHttpClient(customClient) // Does this actually apply?
.build();
Is the SDK supposed to handle connection pooling automatically, or do we need to manage the lifecycle of the OkHttpClient ourselves? Also, is it safe to share one ApiClient instance across multiple threads, or should we be creating a new one per request? Creating a new one per request feels heavy on the OAuth token refresh overhead.
Any pointers on the correct way to configure this for high-concurrency Java apps?