WCF REST StarterKit HttpClient: Timeout from HttpClient when going remote - works fine locally or via local proxy - wcf

Question

I'm getting repeated Microsoft.Http.HttpStageProcessingException timeout exceptions while trying to use the REST Starter kit's HttpClient. This has been working fine when used locally, but is failing when going remote.
The client is a c# process that runs as a windows service and uses HttpClient for making REST calls to our Java app server running in Tomcat6. When I started troubleshooting this, I came across a similar post on MSDN's forums: http://social.msdn.microsoft.com/Forums/en/wcf/thread/88487549-ce45-49d3-95e4-7ed413cbcfbc
Unfortunately, I can't isolate it to simply a Content-Length problem.
If anyone has any suggestions on how to solve this problem, I would greatly appreciate it - even if it means using HttpWebRequest directly. I understand HttpClient uses HttpWebRequest under the hood, but perhaps it's making some assumptions.

Answer 1

Found the solution. It turns out that the default number of outbound http connections when using the HttpClient seems to be 2. After I used the ServicePointManager static singleton to set the DefaultConnectionLimit for my client AppDomain to 10, everything worked fine.
Now, this is a little concerning, however - because I'm used to writing multi-threaded apps and using the new .NET 4 Tasks - so I really don't like having hard limits on outbound connections. Can anyone provide any links that provide details on how the low-level .NET Http handling works and what knobs control what settings?
Thanks again for the help,
Bob
NEVERMIND - found it myself, should have googled first - this MSDN blog on the Http Client protocol provides a good description of what's going on under-the-hood:
httpclient protocol blog

Answer 2

If it works locally or remotely via Fiddler then it is a problem with HTTP proxy. Your current configuration is not using proxy but Fiddler by default uses proxy configured for IE.

Answer 3

Get the same problem and solution is to Dispose method on response (maybe method named Close may be more clear) else response still occupy the socket and you have to increase the DefaultConnectionLimit to open new socket for each new request untill max limit reach (dirty and slow).
So the solution was:
HttpResponseMessage resp = this.HttpClient.Delete(uri);//or verb get/post/put
try {
//.... do what you need with response
}
finally {
resp.Dispose(); //free the socket for a new request
}