再生フレームワーク1.2.4リークhttps接続

Question

httpとhttps要求の両方を処理する再生フレームワーク1.2.4サイトがあります。

Playはリバースプロキシがインストールされていないため、80ポートと443ポートの両方をリッスンします。

しばらくすると、ログに「java.io.IOException：開いているファイルが多すぎます」という応答が停止します。

明らかに、再生はhttps接続をCLOSE_WAIT状態のままにすることがあります。これらの接続は、次のようになります。ご覧のとおり20〜、

$ 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 

：ここ

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

は（16K開いているファイルで）生きている（時間のカップルのために働い）と死者のlsofはダンプの分析でありますリクエストの％はhttpですが、CLOSE_WAIT状態のすべての接続はhttpsです。

何が問題になるか？それはプレーフレームワークのバグでしょうか？

Answer 1

あなたが説明した内容に基づいて、これはPlayのバグであると思われます。それがNettyの問題である可能性がありますが、PlayがNettyと統合されているので、あなたの目的のためにdeliniationは無関係です。 Lighthouseのチケットを手にして、アプリケーションのhttps部分に責任を負うNicolas Lerouxに連絡することをお勧めします。

ただし、Playの開発者は、Playがhttpとhttpsのコンテナではないと主張します。 httpsハンドシェイクは、Apacheなどの前向きプロキシによってうまく実行されます。これをオンラインで行う方法とPlayのドキュメントには多くの例があります。