请求回退连接池创建线程逻辑，使用1.2.21遇到连接池关闭问题的都过来

[codedad1983]

执行单元测试MySqlHexTest就能看到死循环效果：

Caused by: java.net.UnknownHostException: hbase-01
  at java.net.InetAddress.getAllByName0(InetAddress.java:1281)
  at java.net.InetAddress.getAllByName(InetAddress.java:1193)
  at java.net.InetAddress.getAllByName(InetAddress.java:1127)
  at com.mysql.cj.protocol.StandardSocketFactory.connect(StandardSocketFactory.java:130)
  at com.mysql.cj.protocol.a.NativeSocketConnection.connect(NativeSocketConnection.java:63)
  ... 9 more

原因是MySqlHexTest测试类配置的jdbcUrl是jdbc:mysql://hbase-01:3306/sonar，而测试环境并没有配置hbase-01的ip地址。
建议借鉴这个PR的做法，把RunTime异常和SQL异常处理合并，如果一次连接都没有创建成功过，就break中止，否则按原来SQL异常处理分支处理。

Originally posted by @zrlw in #4885 (comment)

@zrlw 你提出的场景与 @shilei1987 描述的问题完全不是一码事。测试环境并没有配置hbase-01的ip地址并不会导致真实物理连接被创建，也不存在消耗数据库连接的问题。如此修改这个创建过程逻辑导致我们应用在启动刚开始的故障自恢复能力完全失效。

建议恢复原始逻辑！！！

[codedad1983]

UnknownHostException之类的网络配置问题，完全可以由连接池自动重试，当网络接通应用就能自动恢复了，搞什么关闭连接池！

关闭之后在并发使用过程又没有处理好并发情况下的restart和init操作，真会添乱。

[codedad1983]

退一万步讲，@zrlw 你这么改顶多算是只解决第一次创建连接的问题，往后的RuntimeException同样存在 #4885 的问题。

[lizongbo]

UnknownHostException之类的网络配置问题，完全可以由连接池自动重试，当网络接通应用就能自动恢复了，搞什么关闭连接池！

关闭之后在并发使用过程又没有处理好并发情况下的restart和init操作，真会添乱。

请详细描述一下你们复现问题的步骤
看上去是启动的时候数据库连不上的也要先创建好连接池，然后这段实际访问异常，但是db恢复之后，系统的db操作再自动恢复正常？

[codedad1983]

请详细描述一下你们复现问题的步骤 看上去是启动的时候数据库连不上的也要先创建好连接池，然后这段实际访问异常，但是db恢复之后，系统的db操作再自动恢复正常？

我觉得你的理解应该是对的。

1.2.20的逻辑就是启动的时候初始化好连接池的各项参数，创建线程就会在后台自动维护链接，出现异常就会自动重试直到满足连接池的预期设定。上层应用无论何时都只要getConnection()即可，无需关心连接池中的异常，只需处理对connection的操作异常。这样的设计隔离性很好，各自的职责也很明确。

1.2.21中在完成init()后通过isInit()得到true的状态下自动关闭连接池的逻辑是否合理？这要让上层应用如何处理？相关代码的修改与 #4885 根本不是一回事，并没有解决问题，还把那个问题关闭了。

基于1.2.21之前的版本，我们应用如果连不上数据库（无论何时，包括启动的时候），那么getConnection()就会阻塞，等待一个超时时间，然后报错，是否重试是否退出就由我们应用来决定（大部分应用都会选择自动重试）。当数据库恢复，连接池的CreateConnectionThread就是会自动把连接重新建起来，配合应用上的重试就自动恢复了。

[codedad1983]

目前看1.2.21版本的逻辑就奇葩了。首次创建连接异常就把连接池关了，而且应用没有任何感知，然后要实现自恢复，我就只能尝试在每次getConnection()之前先判断isClosed()，然后restart()和init()，但是这样在多线程并发的情况下会出现多次不必要的restart()和init()。高并发大压力下会不会出现状态混乱，我还没有测试过。我也想不到什么办法可以把isClosed()，restart()和init()包装成一个高性能的原子操作。

[codedad1983]

所以这个修改大大增加了使用Druid的复杂度，这是要断送Druid当前取得的成就啊？

[lizongbo]

我来恢复一下， 这个fastfail的触发时机确实应该交给应用层，连接池在这种情况下不应该fastfail

[genvyday]

1.2.21这个发布真的可能把druid的名声毁了

[genvyday]

#4885 明显是DruidAbstractDataSource::createPhysicalConnection(String url, Properties info)和FilterChainImpl::connection_connect没有在出现异常时关闭数据库连接导致连接泄露的问题。

退一万步讲，@zrlw 你这么改顶多算是只解决第一次创建连接的问题，往后的RuntimeException同样存在 #4885 的问题。

[zrlw]

连接参数配置错误时，Druid自动重试机制导致错误日志会将磁盘空间占满，有docker用户提出了druid主动关闭的需求。
可以考虑加一个选项，兼顾一下这些用户的需求。
@lizongbo