为什么我不应该使用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？

回答

相关问题