0

http と https の両方のリクエストを処理するプレイ フレームワーク 1.2.4 サイトがあります。

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

しばらくすると、ログに大量の「java.io.IOException: Too many open files」が表示され、サイトが応答を停止します。

どうやら、play は https 接続を CLOSE_WAIT 状態のままにすることがあります。これらの接続は次のようになります。

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

これは、生きている（数時間動作している）および死んでいる（16kの開いているファイルを使用）のlsofダンプの分析です。

$ 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

ご覧のとおり、リクエストの約 20% は http ですが、CLOSE_WAIT 状態の接続はすべて https です。

何が問題を引き起こしている可能性がありますか? それはプレイフレームワークのバグでしょうか?

4

1 に答える 1

2

あなたの説明に基づいて、これは Play のバグのように見えることに同意します。Netty の問題である可能性はありますが、Play は Netty と統合されているため、説明は目的には関係ないと思います。Lighthouse でチケットを発行し、場合によっては、アプリケーションの https 部分を担当する Nicolas Leroux に連絡することをお勧めします。

ただし、Play の開発者は、Play が http および https コンテナーになることを意図していないと最初に言うでしょう。https ハンドシェークは、Apache などのフロント プロキシを使用した方が適切に実行されます。これを行う方法については、オンラインや Play のドキュメントにたくさんの例があります。

于 2012-05-04T10:12:10.173 に答える