Почему время ожидания WebRequest всегда на первом запросе, но никогда на последующих - PullRequest
7 голосов
/ 07 июля 2011

Возникла проблема, когда вызов WebRequest.GetResponse() зависает и время ожидания при первом вызове, но после первого вызова все работает нормально.

        try {
            WebRequest myHttpWebRequest = WebRequest.Create(@"http://192.168.x.x/");
            // Sends the HttpWebRequest and waits for the response.         
            myHttpWebRequest.Timeout = 1000;
            WebResponse myHttpWebResponse = myHttpWebRequest.GetResponse();
        } catch(Exception e) {
            Console.WriteLine("Failure 1");
        }
        try {
            WebRequest myHttpWebRequest = WebRequest.Create(@"http://192.168.x.x/");
            // Sends the HttpWebRequest and waits for the response.         
            myHttpWebRequest.Timeout = 1000;
            WebResponse myHttpWebResponse = myHttpWebRequest.GetResponse(); 
        } catch(Exception e) {
            Console.WriteLine("Failure 2");
        }
        try {
            WebRequest myHttpWebRequest = WebRequest.Create(@"http://192.168.x.x/");
            // Sends the HttpWebRequest and waits for the response.         
            myHttpWebRequest.Timeout = 1000;
            WebResponse myHttpWebResponse = myHttpWebRequest.GetResponse(); 
        } catch(Exception e) {
            Console.WriteLine("Failure 3");
        }

используя этот код в консольном приложении, я всегда получаю Failure 1. Работать под отладчиком или нет. Я сделал цикл 1000 , и он всегда дает сбой на первом, а не на любом другом. Фактически, читая логи веб-сервера, он фактически никогда не получает первый запрос. Я что-то здесь упускаю?

Ответы [ 4 ]

9 голосов
/ 07 июля 2011

РЕДАКТИРОВАТЬ: я понял, что ответ ниже будет соответствовать прямо противоположной ситуации, когда первый запрос работает, а другие нет.Тем не менее, это все еще важно - вы действительно должны избавляться от своих ответов.Также было бы полезно, если при сообщении об ошибке вы также сообщаете об исключении ...

Чтобы выяснить, что здесь происходит, вам действительно нужно использовать что-то вроде WireShark , чтобы выможно увидеть, заключается ли проблема в том, что запрос выполняется, но не отвечает, или же он даже не выполняется.

Интересно, действительно ли проблема в том, что он разрешает прокси,или что-то в этом роде ... и времени для его решения достаточно, прежде чем истечет время ожидания second .Попробуйте увеличить время ожидания.Опять же, это должно быть видно через WireShark.


Вы не избавляетесь от веб-ответа, поэтому пул подключений для второго запроса истекает в ожидании, чтобы восстановить это подключение.

Поместите часть WebResponse в оператор using, и вы, вероятно, обнаружите, что все отлично работает:

using (WebResponse myHttpWebResponse = myHttpWebRequest.GetResponse())
{
}

Это предполагает, что вы действительно делаете что-тос ответом, конечно.В противном случае вы могли бы просто написать:

myHttpWebRequest.GetResponse().Dispose();

:)

3 голосов
/ 01 октября 2015

Может быть немного поздно, но у меня был точно такой же эффект. Наконец, причина была в том, что в сети не было шлюза по умолчанию. Решением было опционально установить request.Proxy = null .

var request = WebRequest.Create(UriString);
request.Timeout = Timeout;
if (_disableProxy)
{
    request.Proxy = null;
}
if (request is HttpWebRequest)
{
    var response = (HttpWebResponse)request.GetResponse();
    responseStream = response.GetResponseStream();

}
if (request is FtpWebRequest)
{
    var response = (FtpWebResponse)request.GetResponse();
    responseStream = response.GetResponseStream();
}
else if (request is FileWebRequest)
{
    var response = (FileWebResponse)request.GetResponse();
    responseStream = response.GetResponseStream();
}

Надеюсь, это поможет.

0 голосов
/ 26 июля 2016

Я столкнулся с той же проблемой, в моем случае я увеличил значение timeout объекта WebRequest, и это сработало!

webRequest.Timeout = int.Parse(60000);

(я установил свойство тайм-аута на 60 секунд).

0 голосов
/ 30 июля 2013

Вы можете получить поведение, очень похожее на это, если вы не сбросили \ не закрыли RequestStream до запроса Ответа. Такое поведение, кажется, существует в .NET 3.5, но было исправлено в .NET Framework 4.5. Я заметил проблему при переключении фреймворков - код (без закрытия), который работал в 4.5, перестал работать при компиляции против 3.5. Возможно, попробуйте явно получить RequestStream и закрыть его как обходной путь.

...