2017-01-26 1 views
0

Я пишу код сервера в ASP.NET и используя структуру MVC. Мой клиентский код - javascript.Как контролировать время ответа AJAX на стороне сервера

Независимо от того, используете ли JQuery или нет запрос AJAX от браузера к серверу, вы можете установить тайм-аут, и, конечно же, у браузера также есть таймаут, который он может обеспечить отдельно. Если достигнут один из этих тайм-аутов, вызывается метод отказа вызова ajax и один из аргументов указывает тайм-аут.

ОДНАКО. Недавно я обнаружил, что сервер может отключить вызов AJAX и завершить с кодом ошибки 500, который клиент получит как код ошибки 500, отличный от любой непредвиденной ошибки. Однако в этом случае основной рабочий процесс сервера продолжается - это только сам веб-сервер (IIS в моем случае), который прерывает и отправляет код ошибки 500, не позволяя работнику знать, чтобы рабочий продолжал блаженно не осознавать, что существует проблема.

Между тем, клиент в обработчике ошибок для вызова AJAX получает статус 500, что, естественно, будет интерпретироваться как отказ рабочего процесса, возможно, необработанное исключение и необоснованное завершение. Насколько я вижу, клиент не может понять, что проблема была таймаутом, отдельно от неожиданного исключения. Таким образом, клиентский код может ошибочно предположить, что рабочий процесс мертв, когда на самом деле он очень живой.

Так .... трехкратный вопрос:

  1. Есть ли способ в MVC ASP.NET для управления настройками времени ожидания сервера?
  2. Есть ли способ для рабочего процесса, который, по мнению сервера, занимает слишком много времени, чтобы быть информированным, если сервер генерирует тайм-аут от его имени?
  3. Есть ли способ для обратного вызова сбоя AJAX на стороне клиента знать, что эта конкретная ошибка 500 заключается не в том, что у работника была непредвиденная ошибка, а потому, что код сервера обертывания решил, что он занимает слишком много времени?

w.r.t. # 3, я вижу, что свойство responseText ответа Ajax содержит некоторый html, который, если визуализировал бы, сказал бы пользователю, что был тайм-аут, но программный синтаксический анализ для этого кажется действительно грязным и ненадежным.

Кто-нибудь еще сталкивается с этим?


ADD/EDIT, 4 вечера PDT на 1/26:

Основываясь на комментарий непосредственно ниже предполагая, что я мог бы найти решение с this article, я реализовал предложенный фильтр. Это не работает. Я смог запустить новый фильтр, явно бросая исключенный исключение тайм-аута из рабочего процесса, поэтому мой фильтр в соответствии с этой другой статьей SO явно работал, но он не был запущен.

Я должен добавить, что это приложение работает как веб-сайт Windows Azure. Я убежден в том, что из-за косвенных данных/данных, которые я смог накопить, что IIS на виртуальной машине сам прерывает запрос и отвечает с ошибкой 500, даже не сообщив основному рабочему процессу или MVC-приложению, что он в итоге прекратил запрос.

Таким образом, это почти похоже на проблему ИТ-специалиста по настройке IIS на этой конкретной виртуальной машине для данного конкретного веб-сайта.

По моим данным, IIS просто отменяет запрос через 230 секунд.

+0

Как насчет фильтра пользовательских исключений и обрабатывать 'TimeoutException' внутри него? Может быть, если это слишком продолжительный процесс, я бы предложил использовать фоновые задания, такие как hangfire.io или signalR, чтобы вызвать клиента с сервера о завершении. – Developer

+0

Что я имею в виду, есть глобальный фильтр, который обрабатывал TimeoutException и преобразовывал статус ответа HTTP код и сообщение на ваш желаемый код md message – Developer

+0

@Developer - Я не совсем уверен, что вы имеете в виду об этом глобальном фильтре. Я считаю, что это IIS, который прерывает запрос .... если у вас есть более конкретные инструкции или можно связать меня с местом, которое я хотел бы попробовать. –

ответ

0

Попробуйте эту запись web.config:

<system.web> 
<httpRuntime executionTimeout="your-timeout-in-seconds"> 
... 
</system.web> 
+0

Спасибо ... это выглядит многообещающим для # 1, но мне потребуется время для тестирования. Благодарен за быстрый ответ. –

+0

Но что произойдет, если процесс займет еще больше времени, чем указано в конфиге? – Developer

+0

@Developer Именно то, что вы ожидаете - ошибка внутреннего сервера клиента. Я считаю, что в теле http-сообщения у вас есть информация о том, что это был тайм-аут сервера, но я не уверен в данный момент. – komsky

Смежные вопросы