Skip to content

Java SDK reuses half open connections after server-side idle close #207

@adamvialpando

Description

@adamvialpando

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions