We’ve got a Java service handling a high volume of Genesys Cloud Data Action calls. The goal is to trace these requests using OpenTelemetry while maintaining performance. I’m using the com.genesyscloud.platform.client SDK.
The issue is connection pooling. When we hit a burst of calls, the underlying HttpClient starts throwing java.util.concurrent.TimeoutException: Timeout waiting for connection from pool. This happens even though I’ve configured the pool size to 50.
Here is the client setup:
ApiClient apiClient = ApiClientBuilder.builder()
.withDefaultClientConfig()
.withHttpClientConfig(config -> {
config.setConnectionPoolSize(50);
config.setConnectionRequestTimeout(5000);
config.setConnectTimeout(10000);
config.setReadTimeout(30000);
})
.build();
I’m injecting the OTel context into the headers before each call like this:
String traceContext = TraceContext.get().toString();
apiClient.setHeader("X-Trace-ID", traceContext);
The error logs show:
io.netty.channel.ConnectTimeoutException: connection timed out: api.mypurecloud.com/54.239.28.10:443
Is the SDK’s internal connection pool shared across all instances of ApiClient? I’m creating a new ApiClient instance per thread in our executor service. If the pool is global, that might explain the exhaustion. Also, does the SDK support passing a custom HttpClient instance for better control over the connection management? We need to ensure the spans are propagated correctly without blocking the thread pool.