From 09282ee21528b1fb7fabb36362b984a23164d993 Mon Sep 17 00:00:00 2001 From: Icemap Date: Tue, 6 Feb 2024 17:36:11 +0800 Subject: [PATCH] feat: align with two docs --- best-practices/java-app-best-practices.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/best-practices/java-app-best-practices.md b/best-practices/java-app-best-practices.md index 2b60787696a5e..a62b7ceffcf72 100644 --- a/best-practices/java-app-best-practices.md +++ b/best-practices/java-app-best-practices.md @@ -228,6 +228,8 @@ The connection pool maintains persistent connections from clients to TiDB as fol - Before v5.4, TiDB does not proactively close client connections by default (unless an error is reported). - Starting from v5.4, TiDB automatically closes client connections after `28800` seconds (this is, `8` hours) of inactivity by default. You can control this timeout setting using the TiDB and MySQL compatible `wait_timeout` variable. For more information, see [JDBC Query Timeout](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout). +Moreover, there might be network proxies such as [LVS](https://en.wikipedia.org/wiki/Linux_Virtual_Server) or [HAProxy](https://en.wikipedia.org/wiki/HAProxy) between clients and TiDB. These proxies typically proactively clean up connections after a specific idle period (determined by the proxy's idle configuration). In addition to monitoring the proxy's idle configuration, connection pools also need to maintain or probe connections for keep-alive. + If you often see the following error in your Java application: ```