使用 HttpClient 似乎会删除 GET 调用
我正在使用 WCF REST 预览版本中的 HttpClient，我们看到了一些我试图确定的奇怪功能。
发生的情况是，偶尔对 RESTful Web 服务进行五个不同的 GET 调用之一时，该调用似乎根本没有触发，但代码似乎认为它已经触发了。我们已经在服务端以及发出请求的盒子上进行了跟踪，并且当发生此问题时我们没有看到任何传出请求。但是，代码会等待整个超时时间，然后抛出超时。我们已经运行了数百次测试，并且只在 GET 调用上看到它，而从未在我们的流程中发生的 POST 调用上看到它。
更有趣的是，当 Fiddler 在发出请求的盒子上运行时，我们根本无法复制该问题。所有请求每次都顺利完成。
有人对可能发生的事情有任何想法吗？
更多信息： 因此，我们重构了调用，仅使用 HttpWebRequest/HttpWebResponse，并将 HttpClient 排除在外，但仍然存在问题。我们已经为每个响应添加了显式的 .Close() 语句，因此我们似乎并没有关闭它们。这是在 Microsoft CRM 异步插件中运行的，因此我也对其进行了标记，以防万一这是 crm 的问题。
I'm using the HttpClient from the WCF REST Preview release, and we're seeing some strange functionality I'm trying to pin down.
What's happening is, sporadically while making one of five different GET calls to a RESTful web service, the call appears to not fire at all, but the code seems to think it has. We've put tracing up both on the service side as well as the box making the request, and we see no outgoing requests when this issue happens. However, the code waits for the entire timeout period and throws a timeout afterwards. We have run hundreds of tests, and only see it on GET calls, never the POST calls that also occur in our process.
Even more interestingly, with Fiddler running on the box making the request, we cannot replicate the issue at all. All requests go through just fine every time.
Anybody have any ideas on what could be going on?
MORE INFO:
So we've refactored our calls to just use HttpWebRequest/HttpWebResponse and take HttpClient out of the equation and are still having issues. We've added explicit .Close() statements to each response, so it doesn't seem to be that we're not closing them. This is running in a Microsoft CRM asynchronous plugin, so I'm tagging that as well, just in case this is an issue with crm.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于您的代码在服务器上以异步进程运行，因此可能会耗尽服务器上的传出 TCP 端口。当您有一个服务器端进程与其他 HTTP 服务器通信时，这种情况很常见。
以下链接进一步描述了该问题，并展示了如何更新服务器上的注册表以优化这些设置。
http://msdn.microsoft.com/en-us/library/ms819739.aspx
Since your code is running on the server in the Async process, it might be running out of outgoing TCP ports on the server. This is quite common when you have a server-side process talking to other HTTP servers.
Here is a link that describes the issue a bit more and shows how to update the Registry on the server to optimize these settings.
http://msdn.microsoft.com/en-us/library/ms819739.aspx
问题确实是连接没有关闭，并且远程服务器限制了与特定 IP 地址的连接数量。结果是 HttpClient 代码为每个实例化创建一个新的 ConnectionGroupName，并且我们在每次调用时都创建一个新的 ConnectionGroupName。即使我们将调用包装在 using 语句中，连接也没有关闭。
我们使用 HttpWebRequest/HttpWebResponse 重写了整个代码，并在每次调用时显式调用 .Close()。这已经解决了这个问题。
我们猜测这些调用都是通过 Fiddler 进行的，因为它要么为我们关闭或汇集连接
The issue did turn out to be that the connections were not being closed, and the remote server was limiting the number of connections to a particular IP address. Turns out that the HttpClient code creates a new ConnectionGroupName for every instantiation, and we were creating a new one with every call. Even though we wrapped the calls in using statements, the connections did not close.
We rewrote the code using HttpWebRequest/HttpWebResponse throughout and explicitly called .Close() on every call. This has taken care of the issue.
We're guessing that the calls all worked through Fiddler because it was either closing or pooling the connections for us