dbcp重连(转) -凯发k8网页登录

使用数据库连接池时，免不了会遇到断网、数据库挂掉等异常状况，当网络或数据库恢复时，若无法恢复连接池中的连接，那必然会是一场灾难。

关于dbcp的自动重连配置，网上相关的资料也不少，通过以下资料，并对照官方文档中的参数说明，大致能了解各项配置的含义，我就不冗诉了，本文的目的主要是对问题排查的经过做个简单的记录。
参考资料：

测试环境：

• dbcp版本——1.4
• 数据库——postgressql 9.10（简称pg）
• 本地(以下称为client)操作系统及数据库服务器(以下称为server)操作系统均为linux
• server位于内网环境，client需要通过vpn或网线直连内网才能访问数据库

首先模拟的是断网的情况
在本地测试dbcp的重连配置时，发现断网后，连接池无法重建连接，分别试过testonborrow和testwhileidle两种validate方式，都没能解决，现象如下：
1. 正常启动应用，在server端通过"select * from pg_stat_activity"查看连接数，会有initialsize个来自client的idle连接。——正常
2. 在client端执行各种查询操作，连接数保持不变，且在server端的db log中能看到validate query。——正常
3. 手动切断vpn，client与server断开，查询无法返回结果；然后重连，再次查看连接数，连接数仍保持不变，且连接的创建时间为断网前，即是说连接池认为之前的连接仍然有效，没有销毁旧连接&创建新连接。
4. 此时在应用中执行各种查询操作，均无响应，等待一段时间后（分钟级），超时抛出异常：
caused by: org.postgresql.util.psqlexception: an i/o error occured while sending to the backend.
caused by: java.net.socketexception: connection timed out.
5. 继续通过"select * from pg_stat_activity"查看连接数，隔一段时间后，连接消失。

问题：断网后，仍留在线程池内的连接是否有效？若有效，为什么网络恢复后查询无响应？若无效，为何线程池没有发现并重新创建有效连接？
排查过程：
1.重连vpn后，通过netstat查看client至server的连接
注：5432为pg端口，grep java是为了过滤client上的其他形式的连接。
发现连接数和在server端看到的连接数一致，且均为establish状态。
2. 但在client上执行查询时，通过tcpdump查看client发往server的tcp请求，并无任何请求产生。
可见当前线程池中的连接实际上已经失效了，但dbcp仍认为它是有效的，因此仍在尝试用旧连接访问数据库，直至网络超时。

于是，开始怀疑是vpn的问题，将client接上网线直连内网后，再次重试上述步骤，只是把断网的方式由切断vpn换成了拔网线，发现这次使用断网前的连接能够正常访问数据库，于是断定是vpn的问题，猜测是重连vpn后，虽然client端ip没有变，但路由的路径已经变了，之前的连接无法复用，但dbcp并不知道。对网络细节不是太熟悉，就不多加揣测了。

接下来模拟数据库断开client连接的情况
由于pg采用的是进程模型，与数据库建立的每一个连接都是单独的一个进程，故尝试采用kill进程的方式模拟数据库断开连接。
预期的结果是：kill掉一个连接进程后，dbcp通过validate query发现该连接失效，将销毁该连接并重新创建新连接。
但实际情况确是：kill掉一个连接后，所有连接全部被销毁。
问题：究竟是数据库还是dbcp销毁了所有连接?
排查过程：
熟悉pg的同事认为pg之所以采用进程模型，就是为了避免连接之间的影响，因此不可能发生kill一个连接，其他连接也被销毁的情况。在这个理论前提下，问题就变得很诡异，因为dbcp的validate肯定是针对一个连接的，也不可能会在validate一个连接失效的情况下销毁所有连接，于是越想越偏，甚至开始怀疑是pg的jdbc driver有问题，最终放弃了深究。
但我总觉得有点不太对劲，于是推翻之前的前提，开始怀疑是pg销毁了所有连接。于是，在使用连接池的应用之外，通过pg的数据库客户端psql连接db，这就建立了一个与dbcp无关的连接，接着继续在server端kill了一个连接池中的连接，继而发现psql创建的连接也被销毁了，这就能确定是pg在销毁连接，因为dbcp不可能控制自身范围之外的连接。
后来才知道，pg之所以会这么做，是因为我们kill连接时使用的是kill -9（简称9杀），9杀太过粗暴，pg会重启很多内部进程，以保证所有进程正常，之前的连接也将会丢失，换用普通的kill命令，则不会发生以上情况。可见9杀很多情况下是十分危险的，试想一个线上db，若是9杀一个连接，后果不堪设想。。。

总结
说是dbcp问题排查，但大家可以看到最终问题的根源都跟dbcp没有什么关系。实际工作中的很多问题，关联的因素众多，需要有各方面的知识储备才能找到真正问题根源，否则就会把问题归结到一个自己不太了解的领域。
另外，看到这篇文章中对连接池重连有两句不错的总结，引用一下：


最后附上测试使用的dbcp配置。
testonborrow配置：
testwhileidle配置：

注：testonborrow只会发现当前连接失效，再创建一个连接供当前查询使用，而testwhileidle会定时校验numtestsperevictionrun个连接，只要发现连接失效，就将其移除再重新创建。