We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.背景: https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8 根据这个参数说明的文档,maxWait参数表示获取连接时最大等待时间,单位毫秒。但是在com.alibaba.druid.pool.DruidDataSource#getConnection(long maxWait)调用时,存在「从连接池取连接」和「探测连接」两个动作,maxWait只能指定「从连接池取连接」这一动作的超时时间,如果存在testWhileIdle=true && idleMillis >= timeBetweenEvictionRunsMillis 或者 testOnborrow=true时,会触发「探测连接」这一动作,这部分超时时间会根据validationQueryTimeout来指定。另外,「从连接池取连接」成功但「探测连接」失败时,还会有重试的逻辑。 存在一种场景,当「从连接池取连接」成功但「探测连接」未设置超时时间,或者「探测连接」重复失败时,可能会导致getConnection调用长时间阻塞。 2. 问题 我理解maxWait对于用户而言,应该表示的是用户在调用DruidDataSource#getConnection时预期的超时时间。但在上述场景下getConnection会长时间阻塞,不符合用户的预期。是否应该考虑将探测时间结合maxWait动态计算,并且修改探测失败就无限重试的逻辑?
The text was updated successfully, but these errors were encountered:
No branches or pull requests
1.背景:
https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8
根据这个参数说明的文档,maxWait参数表示获取连接时最大等待时间,单位毫秒。但是在com.alibaba.druid.pool.DruidDataSource#getConnection(long maxWait)调用时,存在「从连接池取连接」和「探测连接」两个动作,maxWait只能指定「从连接池取连接」这一动作的超时时间,如果存在testWhileIdle=true && idleMillis >= timeBetweenEvictionRunsMillis 或者 testOnborrow=true时,会触发「探测连接」这一动作,这部分超时时间会根据validationQueryTimeout来指定。另外,「从连接池取连接」成功但「探测连接」失败时,还会有重试的逻辑。
存在一种场景,当「从连接池取连接」成功但「探测连接」未设置超时时间,或者「探测连接」重复失败时,可能会导致getConnection调用长时间阻塞。
2. 问题
我理解maxWait对于用户而言,应该表示的是用户在调用DruidDataSource#getConnection时预期的超时时间。但在上述场景下getConnection会长时间阻塞,不符合用户的预期。是否应该考虑将探测时间结合maxWait动态计算,并且修改探测失败就无限重试的逻辑?
The text was updated successfully, but these errors were encountered: