refactoring our internal integration service to use the official Genesys Cloud Java SDK (version 8.x) for high-throughput user provisioning tasks. The service runs on AWS ECS with 4 CPU cores and handles concurrent requests from multiple microservices.
The issue arises when we attempt to configure the underlying HttpClient for better connection pooling. The SDK uses the RestClient class which wraps an Apache HttpClient. By default, it seems to use a basic configuration that does not handle high concurrency well, leading to java.net.SocketTimeoutException and ConnectionPoolTimeoutException during peak loads.
Here is the initialization code we are using:
ApiClient apiClient = ApiClientBuilder.defaultClientBuilder()
.withClientId(config.getClientId())
.withClientSecret(config.getClientSecret())
.withBaseUri("https://api.mypurecloud.com")
.build();
// Attempting to set a custom connection pool
PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
cm.setMaxTotal(200);
cm.setDefaultMaxPerRoute(50);
// The SDK does not expose a direct setter for this, so we are using reflection
// or trying to find if there is a hidden method
Field field = ApiClient.class.getDeclaredField("httpClient");
field.setAccessible(true);
HttpClient originalClient = (HttpClient) field.get(apiClient);
// How do we replace this with our pooled client?
The problem is that the ApiClient class does not provide a public setter for the HttpClient instance after construction. We are forced to use reflection, which is brittle and breaks with SDK updates. even if we inject a pooled client, we are unsure if the SDK’s internal retry logic plays nicely with a shared connection pool in a multi-threaded environment. Are there known issues with thread safety when multiple threads share a single ApiClient instance with a custom connection pool? Or is the recommended pattern to create a new ApiClient per thread, which seems inefficient? We have observed intermittent 401 Unauthorized errors that might be related to token refresh contention in a shared client context. Any insights on the proper way to configure connection pooling without resorting to reflection would be appreciated.