参考postgresql的设计。
增加了用来控制创建连接最大耗时的参数,用来防止在连接阶段,tls握手时出现网络异常,导致创建连接线程一直卡在socketread0,直到sockettimeout。
https://github.com/alibaba/druid/issues/5338
参考postgresql的设计。
增加了用来控制创建连接最大耗时的参数,用来防止在连接阶段,tls握手时出现网络异常,导致创建连接线程一直卡在socketread0,直到sockettimeout。
https://github.com/alibaba/druid/issues/5338
直接在jdbc的connection Properties中加 connectTimeout和loginTimeout不就成了?
直接在jdbc的connection Properties中加 connectTimeout和loginTimeout不就成了?
创建连接的过程中,如果在tcp握手后tls握手时,网络发生异常,就会导致创建连接的线程长时间卡在socketread0,无法创建新连接。导致整个连接池在一个connectTimeout的时间内不可用。
由于sockettimeout通常受限于业务场景无法缩短,可以在创建连接时增加保底的超时时间,使得创建连接和查询两个生命周期的超时控制隔离,保证整个连接池不会长时间不可用。
这个修改只是用异步,告诉调用方超时了,实际上连接还是需要socketTimeout以后才处理,这样会在这个时间点造成大量连接(比如重试)。
这个问题属于tcp重传机制的问题,如果应用场景支持druid连接参数socketTimeout设得比较小,比如设成10秒,客户端10秒收不到应答就主动断开连接能够规避这个问题。 如果应用单个sql执行时间很长,socketTimeout这个参数就不能设置的很小了,只能修改客户端的系统参数net.ipv4.tcp_retries2,这个参数通常linux默认配置是15,而windows默认是5: https://support.microsoft.com/en-us/topic/how-to-modify-the-tcp-ip-maximum-retransmission-time-out-7ae0982a-4963-fa7e-ee79-ff6d0da73db8 linux系统默认tcp_retries2设为15,可能始于电话拨号上网的时代,这个数值意味着linux客户端大约要等15分钟才能判定连接已断开(对方断电、对方拔了网线),而windows默认为5意味着windows客户端只需等大约13秒就能判断对方断电或拔了网线。 除非网络环境差,linux这个内核参数没必要还是默认值15了,调成5和windows一样应该是非常靠谱的,至少某个牛厂系的银行的linux系统都这么改了。