Can Ballerina's HTTP client enforce an idle connection timeout independent of the JDK?

Direct answer

Yes, but conditionally. The Ballerina stdlib http:Client can close idle pooled connections after a configurable interval using its own pool configuration, without waiting for the JDK to reap keep-alive sockets. This is not true for every Ballerina HTTP client implementation: if the client is a wrapper around the JDK HttpClient, idle eviction may still be delegated to the JDK.

Likely explanation versus confirmed facts

The following distinction is likely but should be verified against the installed Ballerina version:

• timeout governs request or socket latency, not pool retention.
• pooling.connectionIdleTimeout governs how long an idle connection may remain in the pool before eviction.
• pooling.connectionTimedOutCallback can notify the application when an idle connection is discarded.
• Moving from JDK 11 to JDK 17 should not, by itself, change Ballerina's idle-eviction semantics when the Ballerina pool owns the connection lifecycle. Underlying socket and TLS reuse behavior may still differ.

Confirmed facts: none are independently verified in this draft. The research summary flags the installed Ballerina/http module version and client implementation as unverified, so treat field names, defaults, and units as subject to change.

Steps for this case

1. Identify the client type and Ballerina/http module version. This detail changes the recommendation because a JDK-backed client may ignore Ballerina pool settings.
2. Configure the stdlib client with an explicit idle timeout and callback, for example:

http:Client client = check new("https://example.com",
    timeout = 30s,
    pooling = {
        maxOpenConnections: 100,
        maxPendingConnections: 1000,
        connectionIdleTimeout: 60s,
        connectionTimedOutCallback: onConnectionTimedOut
    }
);

1. Enable Prometheus metrics on the client and scrape pool gauges before and after an idle period.
2. Send a burst, stop traffic, wait past connectionIdleTimeout, and confirm the callback fires and the open-connection gauge falls.

Missing diagnostic detail

Provide the exact Ballerina/http module version and state whether the client is the stdlib http:Client or a JDK HttpClient-backed wrapper. Without this, the correct configuration path cannot be finalized.

Verification

Run bal --version to confirm the toolchain, then inspect the module documentation for the exact PoolConfiguration record, unit, default idle timeout, and callback signature. A minimal reproduction that sends a burst, goes idle, and asserts the callback fired is the safest way to confirm behavior before production rollout.

Assumptions and uncertainty

• Assumes the stdlib http:Client is in use, not a third-party JDK transport.
• Assumes connectionIdleTimeout is expressed in seconds; verify the unit for the installed version.
• Idle eviction does not limit concurrent burst demand; also review maxOpenConnections, maxPendingConnections, and request timeout.
• JDK 11 versus JDK 17 differences are treated as possible socket-layer variation, not a change to Ballerina pool semantics.