GET calls seem to be dropped using HttpClient

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.

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

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