1.1.22版本出现 GetConnectionTimeoutException: wait millis 30000, active 4 maxActive 300, creating 1, createElapseMillis 22433070

[001xinshijie]

1.1.22 版本中在Oracle 服务物理断恢复后，在6个小时后应用服务报错 提示连接超时，并且大量出现。在重启服务后问题消失。在测试环境验证是通过物理断开网络后，在网络恢复后，应用程序断断续续出现连接超时。配置了keepalive 为false 并且配置了test-on-borrow 为true。

[zrlw]

物理断网导致的问题可能比你预计的要复杂的多，testXXX这些连接检测配置并不能解决物理断网导致的问题。

1. 物理断网相当于网络底层直接RESET，客户端的操作系统收不到tcp挥手通知，所有已建立连接的状态仍然是正常的ESTABLISHED状态，druid连接池里的连接也不会自动关闭，你的应用从druid连接池里取出的连接依然是已经物理断开的连接。
2. 无论是test-on-borrow还是test-on-idle，都是对相关连接执行有效性检测，都是通过获取的tcp连接发送检测sql语句（通常是selec 1）到数据库服务器，即使tcp连接已物理断开，只要客户端tcp发送缓冲区不满，发送tcp报文都会成功，只是收不到服务端的ack应答而已，超时收不到ack应答，tcp底层会自动延时重传，操作系统一直重传到次数超限后才能判定连接已经物理断开，整个重传耗时取决于作系统内核的tcp重传次数。linux这个内核参数是net.ipv4.tcp_retries2，默认15，网络质量好、平均传输的延时短的情况下，耗时约925秒，最坏的情况下耗时约30分钟；windows这个参数是TcpMaxDataRetransmissions，默认5，网络好的情况下耗时13秒就能判断tcp连接已物理断开。

规避物理断网导致的问题通常有两种方式：
（1）调小操作系统内核配置的tcp重传次数，将tcp重传超时控制在能够容忍的时间范围内。优点是不需要应用感知，即使应用要等待数十分钟（不考虑设计问题)才能收到数据库响应的sql也不会误杀，系统自己能精确区分物理断网和数据库服务端响应慢的情况；缺点是需要修改操作系统参数，需要root权限。
（2）应用程序自己设置超时，对于数据库连接而言，通常是在jdbc的连接串里设置socketTimeout参数（不同的数据库参数名称不一样）。缺点是可能不太容易确定设置多少合适：设置小了，数据库服务端执行耗时久才能返回应答的sql会被误杀；设大了，网络物理断开时又不能及时感知。

[zrlw]

从你的贴子看，你的物理断网应该是业务低谷时间段吧，断开后6小时候才有业务。
实际上配置testWhileIdle=true & keepAlive=true (testWhileIdle生效的前提）可能更适合你，如果半夜网络断开了，网络连接都是空闲的，默认每分钟会检测一下空闲连接，即使你用的是linux默认配置，15分钟之后连接池里已经失效的连接都会被自动清空。

[001xinshijie]

font{ line-height: 1.6; } ul,ol{ padding-left: 20px; list-style-position: inside; } 感谢 ***@***.*** 签名由网易邮箱大师定制 在2024年5月24日 ***@***.***> 写道： 物理断网导致的问题可能比你预计的要复杂的多，testXXX这些连接检测配置并不能解决物理断网导致的问题。 物理断网相当于网络底层直接RESET，客户端的操作系统收不到tcp挥手通知，所有已建立连接的状态仍然是正常的ESTABLISHED状态，druid连接池里的连接也不会自动关闭，你的应用从druid连接池里取出的连接依然是已经物理断开的连接。 2.无论是test-on-borrow还是test-on-idle，都是对相关连接执行有效性检测，都是通过获取的tcp连接发送检测sql语句（通常是selec 1）到数据库服务器，即使tcp连接已物理断开，只要客户端tcp发送缓冲区不满，发送tcp报文都会成功，只是收不到服务端的ack应答而已，超时收不到ack应答，tcp底层会自动延时重传，操作系统一直重传到次数超限后才能判定连接已经物理断开，整个重传耗时取决于作系统内核的tcp重传次数。linux这个内核参数是net.ipv4.tcp_retries2，默认15，网络质量好、平均传输的延时短的情况下，耗时约925秒，最坏的情况下耗时约30分钟；windows这个参数是TcpMaxDataRetransmissions，默认5，网络好的情况下耗时13秒就能判断tcp连接已物理断开。 规避物理断网导致的问题通常有两种方式： 调小操作系统内核配置的tcp重传次数，将tcp重传超时控制在能够容忍的时间范围内。优点是不需要应用感知，即使应用要等待数十分钟（不考虑设计问题)才能收到数据库响应的sql也不会误杀，系统自己能精确区分物理断网和数据库服务端响应慢的情况；缺点是需要修改操作系统参数，需要root权限。 应用程序自己设置超时，对于数据库连接而言，通常是在jdbc的连接串里设置socketTimeout参数（不同的数据库参数名称不一样）。缺点是可能不太容易确定设置多少合适：设置小了，数据库服务端执行耗时久才能返回应答的sql会被误杀；设大了，网络物理断开时又不能及时感知。 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>