2

PoolingClientConnectionManager を使用していますが、接続がリークしているのではないかと疑っています。以下のように PoolStats を出力する監視スレッドがあります。

[leased: 126; pending: 0; available: 14; max: 140]
..
[leased: 140; pending: 20; available: 0; max: 140]
..
[leased: 140; pending: 10; available: 0; max: 140]

プール接続の数 (140) と同じ数のスレッドを生成したので、リース + 保留中 > 最大になるとは予想していませんでした。この仮定は有効ですか? それとも、これはマネージャーによって接続が維持されている場合ですか? この場合、接続が「リース」または「利用可能」に起因するかどうかはわかりません。

私が気付いたのは、DNS 解決中に HttpClient 接続が中断されると、接続リークが発生する可能性があることです。このシナリオでは、リースされた接続はプールに解放されません。接続がプールに適切に解放されるように、適切なリソースの割り当てを解除する方法はありますか?

前もって感謝します。

4

1 に答える 1

2

はい、接続リークが発生している可能性が非常に高いようです。ただし、DNS ルックアップが原因である可能性は低いです。HttpClient は、I/O、プロトコル、またはランタイム例外が発生した場合に、接続を自動的に解放することになっています。

リソースの割り当て解除に関する限り、ルールは非常に単純です。応答に関連付けられたエンティティがある限り、そのコンテンツが完全に消費されるようにする必要があります。HttpClient 4.2 および HttpClient 4.3は、例外的な場合にリソースの割り当てを解除するための追加のセーフガードも提供しますHttpUriRequest#releaseConnection: 4.2および4.3CloseableHttpResponse#close

ここで説明されているように、接続管理コンテキストのログ記録をオンにしてアプリケーションを実行してみて、基になる接続を決して解放しない要求を追跡するのに役立つかどうかを確認することもできます。

于 2013-09-07T16:21:28.680 に答える