Summary
When flagsmith-java-client reuses a pooled HTTP connection that has been closed by the server (or an intermediate load balancer) after a short idle timeout, the FIN/GOAWAY signal can be lost in transit. The SDK then reuses the half open socket and the request hangs until the read timeout fires, producing intermittent timeouts on server-side flag evaluations.
FlagsmithConfig currently constructs OkHttpClient internally and never calls .connectionPool(...), so the client runs on OkHttp's defaults: 5 idle connections held for 5 minutes (300 seconds). If anything between the client and the Flagsmith API closes idle sockets sooner than 300s (e.g. AWS ALB default 60s, nginx default 75s), connections go stale before OkHttp evicts them.
Reproduced against both v7.4.3 and v8.0.2. See src/main/java/com/flagsmith/config/FlagsmithConfig.java lines 54-73:
OkHttpClient.Builder httpBuilder = new OkHttpClient.Builder()
.connectTimeout(builder.connectTimeoutMillis, TimeUnit.MILLISECONDS)
.writeTimeout(builder.writeTimeoutMillis, TimeUnit.MILLISECONDS)
.readTimeout(builder.readTimeoutMillis, TimeUnit.MILLISECONDS);
// ... sslSocketFactory, interceptors, proxy, protocols ...
this.httpClient = httpBuilder.build();
No ConnectionPool configuration, and httpClient is private final with no Builder hook to inject a pre-built OkHttpClient.
Describe the solution you'd like.
Add a connectionPool(ConnectionPool pool) method to FlagsmithConfig.Builder and call httpBuilder.connectionPool(builder.connectionPool) inside the construction block when set. This lets callers tune keepAliveDuration and maxIdleConnections to match their network environment:
FlagsmithConfig config = FlagsmithConfig.newBuilder()
.connectionPool(new ConnectionPool(5, 30, TimeUnit.SECONDS))
.build();
Additional context
Raised by a customer running flagsmith-java-client:7.4.3. The failure mode is consistent with the documented OkHttp behavior of holding idle pooled connections for up to 5 minutes by default. Same gap appears to exist in v8.0.2.
Summary
When
flagsmith-java-clientreuses a pooled HTTP connection that has been closed by the server (or an intermediate load balancer) after a short idle timeout, theFIN/GOAWAYsignal can be lost in transit. The SDK then reuses the half open socket and the request hangs until the read timeout fires, producing intermittent timeouts on server-side flag evaluations.FlagsmithConfigcurrently constructsOkHttpClientinternally and never calls.connectionPool(...), so the client runs on OkHttp's defaults: 5 idle connections held for 5 minutes (300 seconds). If anything between the client and the Flagsmith API closes idle sockets sooner than 300s (e.g. AWS ALB default 60s, nginx default 75s), connections go stale before OkHttp evicts them.Reproduced against both
v7.4.3andv8.0.2. Seesrc/main/java/com/flagsmith/config/FlagsmithConfig.javalines 54-73:No
ConnectionPoolconfiguration, andhttpClientisprivate finalwith no Builder hook to inject a pre-builtOkHttpClient.Describe the solution you'd like.
Add a
connectionPool(ConnectionPool pool)method toFlagsmithConfig.Builderand callhttpBuilder.connectionPool(builder.connectionPool)inside the construction block when set. This lets callers tunekeepAliveDurationandmaxIdleConnectionsto match their network environment:Additional context
Raised by a customer running
flagsmith-java-client:7.4.3. The failure mode is consistent with the documented OkHttp behavior of holding idle pooled connections for up to 5 minutes by default. Same gap appears to exist inv8.0.2.