它怎么又去了。

最近找工作啊，要是哪们郑州的同鞋有好工作，请推建一下，某某不胜感激，请客吃饭自然不必多说。好吧直接讲故事吧。

一同事说那谁谁，你写的代码是不是有问题啊，相同的报文发了两次，哪个领导发来邮件了，附件中是证据。

我心想"我怎么这么苦B吧，别人走了留下的代码，交接给别人了，怎么又成我负责了，但又不能直说，怎么办，闷头解决吧！”，于是乎这场战斗就打响了。

第一步，首先分析了一个重发这一块的代码。很简单用的httpurlconnection请求远程服务器，发现里面有些代码不是很好，但是也不足以产生这个bug,报着蒙

            的思想改过后，发布到服务器上，由于报文重发这种现像是在并发量大的时候产生的，没法测试，所以只能等问题出来了。

第二步，果不其然，该来的总会来的，它又来了，看来这的问题，好吧，抓包吧。系统采用的是集群管理，负载用的nginx在A上，两台tomcat分别在B，C上。在A上抓发往BC的包，在B和C上抓请求别的服务器的包(抓包命令就不写了，网上一搜太多了)。等 布好了天罗地网，就等着这条大鱼出现了。

第三步，分析抓包结果，问题是A发往B、C各一次，A发往B或C后，若1分钟后B/C服务器没有响应，则发往另一台服务器。（http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream）nginx中有一段话  

If an error occurs during communication with a server, the request will be passed to the next server, and so on until all of the functioning servers will be tried. If a successful response could not be obtained from any of the servers, the client will receive the result of the communication with the last server.

就是说其中一台服务器出问题的时候，nginx会发往其它服务器处理。

第四步，为什么我的服务器会出问题，那段代码又没有问题，难道是其它问题。好吧，如果无法定位问题，就跟踪问题，从入口开始到进入请求处理逻辑结束，凡是有IO操作的，我都加上时间输出，最终发现问题出现在和数据库的连接池。连接池用的是dbcp，本身该插件是没有问题的，是我们配置出错了，数据库连接池连接配置过少，maxwait等待时间未设置，这就会造成。A转发请求到B后，B请求数据库连接，但是连接现在如果都是被占用的，好吧，等吧！超过一分钟后（该时间是在nginx.conf中设置），A认为B没有回应，A断开与B的连接 ，但是B的请求并未结束，B等 到有可用数据库连接后，断续执行。A断开连接后，发送请求到C,C也可能成功，或许失败。现在nginx认为处理完了，得到结果后，返回结果。

此文章只是一种问题解决思路，没有提供图片和代码，请各位客官见谅。