爲什麼我不應該使用PoolingHttpClientConnectionManager和FutureRequestExecutionService？

我在寫一個需要運行很多並行http請求的服務。它也將部署在自動擴展環境中，但我希望儘可能多地從每個服務實例中獲得儘可能多的性能。爲什麼我不應該使用PoolingHttpClientConnectionManager和FutureRequestExecutionService？

我遇到這個帖子How to determine the maximum number of simultaneous connections for a given `HttpClient` instance，並注意到不要混合這兩個類的建議。

我很好奇爲什麼。基本上，我想提交http客戶端作業到一個執行器服務，我希望http連接池到位以重用http連接。也許，我過度思考這一點，但我不明白爲什麼在一個應用程序中結合這兩個類/概念是一個壞主意。

另外，我注意到例子中給出的答案每個FutureRequestExecutionService使用一個http客戶端實例。。。這讓我有點緊張，但CloseableHttpClient是線程安全的，所以也許我很擔心不必要的。

此外，對於我的代碼提交的大多數客戶端任務，我不在乎響應是否爲200，如果不是，我只是計劃增加錯誤跟蹤度量並可能記錄異常，所以我正在考慮去回調路線。在那個筆記上，我不清楚回調會在哪裏運行。如果我的線程池線程運行並完成，即不阻止http請求未來。。。那麼什麼線程運行回調代碼？

來源

2017-07-04 matthewcummings516

有問題的帖子建議針對「...... PoolingHttpClientConnectionManager和FutureRequestExecutionService接線代碼的緊密耦合......」。沒有理由不使用FutureRequestExecutionService和PoolingHttpClientConnectionManager。

來源

2017-07-04 09:16:59 oleg

哦，嘿，我希望你能回答@oleg，謝謝！偉大的，關於我的回調方法的任何想法？大多數情況下，當請求收到40x或50x響應時，我只會關心並只寫日誌消息。 – matthewcummings516

爲什麼我不應該使用PoolingHttpClientConnectionManager和FutureRequestExecutionService？

回答

相關問題