🙉How can OkHttp's connection pool detect DNS changes for existing connections? KeepAlive strategy is ineffective under continuous requests.

[wynhfy]

When using OkHttp’s connection pool, if the DNS resolution of a target domain changes , how can existing established connections be made aware of and respond to these changes?
OkHttp only performs DNS resolution when opening a new connection.Existing connections in the pool continue to send requests to the old IP address as long as they are kept alive and not idle.If there is a steady flow of requests, connections never become idle, so keepAlive settings (maximum idle duration) have no effect on cleaning up these stale connections.

[yschimke]

There isn't particularly any built in support in OkHttp for this.

OkHttp does provide hooks you can use to handle these changes.

For a similar case detecting Android network changes (wifi to cell) you would typically use a Call.Factory to switch to a different client with a separate connection pool.

But you could also listen to dns changes and clear the connection pool.

[wynhfy]

There isn't particularly any built in support in OkHttp for this.

OkHttp does provide hooks you can use to handle these changes.

For a similar case detecting Android network changes (wifi to cell) you would typically use a Call.Factory to switch to a different client with a separate connection pool.

But you could also listen to dns changes and clear the connection pool.

Why is setting timetolive not supported? , so that any connection will be closed and recreated after a certain lifetime, regardless of whether it is idle or actively used? This mechanism could help the client "self-heal" by ensuring connections are refreshed periodically (for example, in case of DNS changes or server-side updates).

Is there any design consideration or technical challenge behind the lack of such a feature?

[swankjesse]

We're expecting your server to implement it by sending connection: close when it wants the client to renegotiate DNS.

The server is the right place for this decision because it requires no client-side configuration, it works on all clients, and because the server can make this decision correctly whereas clients will likely do thousands of unnecessary reconnects for every useful reconnect.

If you'd like to do this client-side, add a network Interceptor that adds connection: close when you'd like to close the connection after its in-flight calls complete.

[swankjesse]

Added this, so the thing above could be much easier.
#9219

[wynhfy]

Added this, so the thing above could be much easier. #9219

Yes, if we know the lifespan of the connection and can close it upon expiration, it can help with the self-healing of this issues.