Playframework play framework 1.2.4泄漏https连接

我有一个play framework 1.2.4站点，可以处理http和https请求

Play同时监听80和443端口，未安装反向代理

一段时间后，站点停止响应，日志中出现大量“java.io.IOException:打开的文件太多”

显然，play有时会使https连接处于关闭等待状态。这些连接如下所示：

java    24151 root  201u  IPv6             915797      0t0      TCP Ubuntu-1004-lucid-64-minimal:https->xdsl.******.net:55055 (CLOSE_WAIT)

下面是对活动（工作几个小时）和死亡（打开16k文件）的lsof转储的分析：

如您所见，大约20%的请求是http，但处于CLOSE_WAIT状态的所有连接都是https

---

什么可能会引起麻烦？这可能是游戏框架中的一个bug吗

根据您所描述的，我同意这似乎是一个正在起作用的bug。这可能是内蒂的问题，但随着游戏与内蒂的结合，我认为这种否认与你的目的无关。我建议在Lighthouse上提高一张罚单，并可能联系Nicolas Leroux，他负责应用程序的https部分

---

然而，Play开发者会第一个说Play不打算成为http和https容器。https握手最好由前置代理（如Apache）执行。在线和播放文档中有很多关于如何执行此操作的示例

是的，我知道配置代理是首选，但我的应用程序需要相当复杂的httphttps重定向逻辑，将此逻辑移动到代理中，从应用程序层移出似乎很容易出错。您不将逻辑移动到代理层，而是在代理层进行握手

$ grep "CLOSE_WAIT" dead.txt | wc -l
10473
$ grep "ESTABLISHED" dead.txt | wc -l
1888
$ grep "https.*CLOSE_WAIT" dead.txt | wc -l
10473
$ grep "https.*ESTABLISHED" dead.txt | wc -l
1621

$ grep "CLOSE_WAIT" alive.txt | wc -l
7
$ grep "ESTABLISHED" alive.txt | wc -l
50
$ grep "https.*CLOSE_WAIT" alive.txt | wc -l
7
$ grep "https.*ESTABLISHED" alive.txt | wc -l
32