Диагностирование “Запроса привело к таймауту” HttpExceptions
Это потому, что вы используете EditorFor вместо чего-то определенного, например TextBoxFor.
@Html.TextBoxFor(model => model.Name, new { htmlAttributes = new {
@class = "form-control" }, autofocus="autofocus"})
Или вы можете сделать это с помощью jQuery:
<div class="editor-field focus">
@Html.EditorFor(model => model.Description)
@Html.ValidationMessageFor(model => model.Description)
</div>
$(function() {
$('.focus :input').focus();
});
Update: Как вы знаете, TextBoxFor всегда создает текстовое поле с типом ввода, но EditorFor является немного умный, он отображает разметку на основе типа данных свойства.
6 ответов
При выполнении IIS 7, Вы могли бы использовать Неудавшийся Запрос, Прослеживающий . Я на самом деле не использовал его для тайм-аутов, я главным образом настроил его для получения просто определенных кодов ошибки HTTP. Но я знаю, что можно заставить его выводить трассировки любого запроса, берущего больше чем X количества времени.
Вы попытались отправить вручную через telnet и просто не завершить POST. Мне было бы интересно видеть, могли ли Вы копировать поведение, Вы видите. Учитывая природу сайта, я не был бы удивлен, заставляли ли Вы несколько уродливых СООБЩЕНИЙ намеренно пытаться взломать систему.
я заметил при случае, что должен перезапустить Safari для получения НАСТОЛЬКО рабочим снова после того, как некоторое действие зависает, но я предположил, что это была моя проблема.
Мы раньше видели тех много с нашим веб-клиентом очень интенсивного трафика - удивление, если это связано. То, что, предположительно, происходило, было HttpWebRequest (я предполагаю, что у Вас есть проблемы с HttpWebResponse? Возможно, у них есть те же проблемы), использует некоторый janky пул потоков под покрытиями, , даже когда Ваши запросы синхронны. Время от времени что-то зашло бы в тупик, потому что некоторый другой объект.NET выше в стеке использовал тот же системный пул потоков, и можно было бы исчерпать ресурсы другой, в конечном счете вызвав тайм-аут. Я думаю, что проблема лучше описана здесь: http://www.deez.info/sengelha/2005/03/03/beware-threadpools-and-httpwebrequest/
Я также просканировал бы IP-адреса в Ваших журналах, чтобы видеть - ли это те же люди, имеющие проблемы неоднократно. Вы знаете, просто возможно, что некоторые люди все еще используют набор, считает, или могут быть другие сетевые проблемы об их конце. Но, конечно, не просто спишите его, не занимаясь расследованиями так, как Вы можете.
Мы испытываем тот же "Запрос, приведенный к таймауту" проблема с нашими веб-серверами после переключения от IIS6 до IIS7. Я полагаю, что проблема IIS7-конкретна. Мое предположение - то, что эти ошибки глотали или проигнорировали далее цепочка обработки в IIS6, прежде чем запрос был вручен - прочь ASP.NET для обработки. Я включаю Неудавшийся Запрос, Прослеживающий сегодня, чтобы видеть, могу ли я больше захватывать информацию о проблеме. До сих пор кажется, что Ваше объяснение клиентских причин кажется самым допустимым.
У меня есть та же проблема на наших рабочих серверах, которые используют небольшой веб-сервис Ajax. После выполнения захватов пакетов вне нашего брандмауэра мы нашли, что POST к сервису прибывал в два сегмента TCP, и второй сегмент никогда не добирался до нас. (первый пакет только содержит заголовки, второй отсутствующий пакет должен быть json телом), Так в основном, IIS просто находится, там ожидая остальной части POST. После настроенного тайм-аута сервер отправляет пакет RST клиенту и регистрируется, "Запрос привел к таймауту" ошибки - который является корректным поведением.
Мы пытаемся получить клиентскую репродукцию без большой удачи, но в нашем случае это, кажется, абсолютно сетевое связанный (или возможно некоторое программное обеспечение "безопасности", которому не нравится содержание сообщения).