WCF REST StarterKit HttpClient:远程时 HttpClient 超时 - 在本地或通过本地代理工作正常

发布于 2024-10-06 09:51:19 字数 601 浏览 6 评论 0 原文

在尝试使用 REST Starter 工具包的 HttpClient 时,我重复出现 Microsoft.Http.HttpStageProcessingException 超时异常。这在本地使用时工作正常,但在远程使用时失败。

客户端是作为 Windows 服务运行的 ac# 进程,并使用 HttpClient 对在 Tomcat6 中运行的 Java 应用程序服务器进行 REST 调用。当我开始解决此问题时,我在 MSDN 论坛上看到了类似的帖子: http://social.msdn.microsoft.com/Forums/en/wcf/thread/88487549-ce45-49d3-95e4-7ed413cbcfbc

不幸的是,我无法将其隔离为简单的内容长度问题。

如果有人对如何解决这个问题有任何建议,我将不胜感激 - 即使这意味着直接使用 HttpWebRequest。我了解 HttpClient 在底层使用 HttpWebRequest,但也许它做了一些假设。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

为你拒绝所有暧昧 2024-10-13 09:51:19

找到了解决方案。事实证明,使用 HttpClient 时的默认出站 http 连接数似乎是 2。在我使用 ServicePointManager 静态单例将客户端 AppDomain 的 DefaultConnectionLimit 设置为 10 后,一切正常。

然而现在,这有点令人担忧 - 因为我习惯于编写多线程应用程序并使用新的 .NET 4 任务 - 所以我真的不喜欢对出站连接进行硬性限制。 任何人都可以提供任何链接来提供有关低级 .NET Http 处理如何工作以及哪些旋钮控制哪些设置的详细信息吗?

再次感谢您的帮助,
Bob

NEVERMIND - 我自己找到的,应该先用 google 搜索一下 - 这个关于 Http 客户端协议的 MSDN 博客很好地描述了底层的情况:
httpclient 协议博客

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

孤独患者 2024-10-13 09:51:19

如果它在本地或通过 Fiddler 远程工作,那么这是 HTTP 代理的问题。您当前的配置未使用代理,但 Fiddler 默认使用为 IE 配置的代理。

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.

杀手六號 2024-10-13 09:51:19

遇到同样的问题,解决方案是在响应上使用 Dispose 方法(也许名为 Close 的方法可能更清楚),否则响应仍然占用套接字,并且您必须增加 DefaultConnectionLimit 才能为每个新请求打开新套接字直到达到最大限制(脏且慢)。

所以解决方案是:

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
}

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
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文