We are migrating our Genesys Cloud Data Action orchestrators to Java to reduce latency. The goal is to inject OpenTelemetry context into every outbound call.
Currently, we instantiate a new ApiClient inside each Data Action execution. This kills performance. We need to share an HttpClient instance across threads while ensuring the Authorization header updates correctly for each tenant context.
Here is the setup:
public class GcClientFactory {
private static final CloseableHttpClient httpClient = HttpClients.custom()
.setMaxConnTotal(100)
.setMaxConnPerRoute(20)
.build();
public static ApiClient getClient(String tenantId, String token) {
// How to attach this to the shared httpClient?
return new ApiClient(tenantId, token);
}
}
The issue is that ApiClient creates its own internal HTTP client. We can’t seem to inject our pooled CloseableHttpClient without breaking the SDK’s internal auth interceptors.
Is there a supported way to override the HTTP client in the Java SDK? Or should we bypass the SDK entirely and use raw RestTemplate with manual token handling?
Also, we are seeing ConnectionPoolTimeout errors when concurrent requests exceed 50. The default pool seems too small for our trace volume.
Any code examples for a thread-safe factory pattern that works with the Genesys Java SDK? We need to keep the OTel span context attached to each request. The current setup drops traces when the pool locks up.
Also, does the SDK support async/await patterns for non-blocking I/O? We are running on a reactive stack.