记一次 HttpClient 连接半释放导致的问题

问题描述

启动 0.9.2 版本的 hugegraph-server 和 hugegraph-studio，随便执行两条查询语句，然后停止 hugegraph-server，再启动，提示 “8080 端口被占用”。

问题定位

Step 1

最开始没仔细想，主要也是因为对 TCP 这块没啥实际经验，乍一看以为是 studio 每次执行 gremlin 建立一个连接且连接未关闭导致的问题。于是简单的在 studio
每个请求处理完成后将 HugeClient 关闭掉，即 finally{ client.close() }，然后测试，每个请求处理完，连接都正常关闭，然后停止 hugegraph-server
再重启，果然就没问题了，看来这个问题很简单嘛。

但是这么搞总觉得太暴力了，按照书上和博客的说法，连接的建立/释放都是不小的开销，咱能不能重用他呢？

Step 2

在 studio 中重用 HugeClient 也很简单，简单点的话，把它定义为静态的，然后请求入口处以单例的形式获取 HugeClient 即可。我在 loader 中已经写过一个
HugeClientWarpper，所以这里也很快完成。再次测试，除第一次请求创建了一个连接外，后面的请求都没有创建新的连接，看起来节约了开销。然后停止
hugegraph-server 再重启，结果又提示了 “8080 端口被占用”。再查看 studio 进程的 TCP 连接使用情况，发现还是有一个处于 CLOSE_WAIT 状态的连接，
并且这个连接一直不会关闭。

除了停止 hugegraph-server 会产生 CLOSE_WAIT 的连接外，让 hugegraph-server 闲置一会也会在 studio 进程中产生 CLOSE_WAIT 状态的连接，但是只要
studio 再请求一次，那个 CLOSE_WAIT 状态的连接会消失，然后产生一个新的 ESTABLISHED 状态的连接。

走到这里其实会发现两个问题：

为什么即使不停止 hugegraph-server 也会产生 CLOSE_WAIT 状态的连接？
为什么 CLOSE_WAIT 状态的连接不会自己消失，而是要等到 studio 再请求一次才会消失？

Step 3

要解释第一个问题，得找到 TCP 连接关闭的四次握手时序图

image.png

可以看到，连接关闭中只有被动关闭的一方才会出现 CLOSE_WAIT 状态，所以肯定是 hugegraph-server 主动关闭了连接。

然后发现 RestServer 有一个 KeepAlive IdleTimeout，闲置超过此时间的连接会被 jersey 关闭。

The time in seconds to keep an inactive connection alive.

这个参数的默认值为 30 秒，我们将其修改为 60，验证确实符合预期。

这里插一句题外话，KeepAlive 除了有 IdleTimeout 参数，还有一个 Max Requests Count。

The max number of HTTP requests allowed to be processed on one keep-alive connection.

这个参数的意思是：当一个连接处理的请求数超过该值了，就将其关闭。默认为 256，我们将其修改为 5，但是经过调试发现，在处理完第 6 个请求之后才会关闭连接，
而不是我们设置的 5。调试代码：

private boolean checkKeepAliveRequestsCount(final HttpContext httpContext) {
    if (!allowKeepAlive) {
        return false;
    }
    
    final KeepAliveContext keepAliveContext = keepAliveContextAttr.get(httpContext);
    final int requestsProcessed = keepAliveContext.requestsProcessed++;
    final int maxRequestCount = keepAlive.getMaxRequestsCount();
    final boolean isKeepAlive = (maxRequestCount == -1 ||
            keepAliveContext.requestsProcessed <= maxRequestCount);
    
    if (requestsProcessed == 0) {
        if (isKeepAlive) { // New keep-alive connection
            KeepAlive.notifyProbesConnectionAccepted(keepAlive,
                    keepAliveContext.connection);
        } else { // Refused keep-alive connection
            KeepAlive.notifyProbesRefused(keepAlive, keepAliveContext.connection);
        }
    }

    return isKeepAlive;
}

关键在于keepAliveContext.requestsProcessed <= maxRequestCount，当处理完第一个请求，keepAliveContext.requestsProcessed的值为1，
第二个请求值为2 ... 第五个请求为5，仍然是满足 <= 5 条件的，这时仍然认为这个连接是 KeepAlive 的，直到处理完第六个才不满足条件，才会进行关闭连接的操作。

我觉得这是一个 BUG，至少这个参数的说明与表现不符。但是找了半天也没找到该往 github 的哪个仓库反馈。

Step 4

为什么 CLOSE_WAIT 状态的连接不会自己消失，而是要等到 studio 再请求一次才会消失？

这里得跟踪 HttpClient 的代码，我们以服务端关闭了连接，studio 的连接变成了 CLOSE_WAIT 之后作为调试起始点，在PoolingHttpClientConnectionManager
和AbstractConnPool中获取连接和关闭连接的代码处加了很多断点，经过一番折腾，终于发现，在AbstractConnPool的getPoolEntryBlocking方法中找到了第二个
问题的答案。下面给出关键代码：

private E getPoolEntryBlocking() {

    ...
    while (entry == null) {
        ...

        else if (this.validateAfterInactivity > 0) {
            if (entry.getUpdated() + this.validateAfterInactivity <= System.currentTimeMillis()) {
                if (!validate(entry)) {
                    entry.close();
                }
            }
        }
        ...
    }
    ...
}

从if (!validate(entry))一直往里跟会走到AbstractHttpClientConnection的isStale()方法，该方法会尝试从socket的InputBuffer中读一点数据，
读不到就认为stale，然后validate(entry)验证失败，调用entry.close()将连接关闭。

说到这里基本上已经弄明白了上面这两个问题，但其实还有一个问题不太清楚。

服务端主动关闭连接导致客户端处于 CLOSE_WAIT 状态，但是根据四次握手的流程图，为什么服务端没有卡在 FIN-WAIT1 的状态，而是直接就消失了，就好像是正常关闭了一样。