Idle Connection Closed Prematurely in gRPC Java Client Due to Platform‑Dependent Default Timeout

When using the gRPC Java Netty transport, long‑running services occasionally observe that idle connections are closed after a short period of inactivity, even though no explicit idle timeout has been configured.

The library selects a platform‑dependent default value for the Netty idle‑timeout handler, and the exact number is not documented in the API reference. This makes it difficult to predict whether a connection will survive hours or days without traffic, especially when keepalive is disabled.

What is the precise default idle‑timeout value applied on Linux, Windows, and macOS? How does this default interact with Netty’s IdleStateHandler and any server‑side keepalive settings? Should applications explicitly set a custom idle timeout via ManagedChannelBuilder.idleTimeout, and if so, what value is considered safe for services that expect multi‑hour idle periods?