WCF REST StarterKit HttpClient: время ожидания от HttpClient при удаленном доступе - работает нормально локально или через локальный прокси

Question

Я получаю повторные исключения Microsoft.Http.HttpStageProcessingException при попытке использовать HttpClient из набора REST Starter.Это работает нормально при локальном использовании, но не работает при удаленном доступе.

Клиент - это процесс ac #, который работает как служба Windows и использует HttpClient для выполнения вызовов REST на нашем сервере приложений Java, работающем в Tomcat6.Когда я начал устранять это, я наткнулся на похожую запись на форумах MSDN: http://social.msdn.microsoft.com/Forums/en/wcf/thread/88487549-ce45-49d3-95e4-7ed413cbcfbc

К сожалению, я не могу выделить ее просто как проблему длины содержимого.

Если у кого-то естьЛюбые предложения о том, как решить эту проблему, я был бы очень признателен, даже если это означает использование HttpWebRequest напрямую.Я понимаю, что HttpClient использует HttpWebRequest под капотом, но, возможно, он делает некоторые предположения.

Answer 1

Нашел решение. Оказывается, что по умолчанию число исходящих http-подключений при использовании HttpClient составляет 2. После того, как я использовал статический синглтон ServicePointManager, чтобы установить для DefaultConnectionLimit для моего клиентского домена AppDomain значение 10, все работало нормально.

Однако, это немного касается - потому что я привык писать многопоточные приложения и использовать новые задачи .NET 4 - поэтому мне действительно не нравится иметь жесткие ограничения на исходящие соединения. Может ли кто-нибудь предоставить какие-либо ссылки, в которых подробно описано, как работает низкоуровневая обработка .NET Http и какие ручки управляют какими настройками?

Еще раз спасибо за помощь, Боб

NEVERMIND - нашел его сам, следовало бы сначала погуглить - этот блог MSDN по протоколу Http Client предоставляет хорошее описание того, что происходит внутри: протокол протокола httpclient

Answer 2

Получите ту же проблему, и решение для 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
}

Answer 3

Если он работает локально или удаленно через Fiddler, то это проблема с HTTP-прокси.Ваша текущая конфигурация не использует прокси, но Fiddler по умолчанию использует прокси, настроенный для IE.