Соединение было сброшено ASP.NET

Question

У меня есть код, который извлекает данные из базы данных SQL, а затем пронумерует записи, чтобы сгенерировать строку, которая в конечном итоге будет записана в текстовый файл.

Код работает нормально на моем локальном, от VS, но на реальном сервере, примерно через минуту и ​​половину, я получаю ошибку «Нет данных» (хром). Код останавливается в середине цикла через DataTable. Поддержка хостинга «Ошибка сброса соединения» была выбрана.

Я не уверен, что это проблема с тайм-аутом или что-то. Я установил executeTimeout в свой web.config (с debug = false), и это, похоже, не помогло. Я также проверил Сервер. ScriptTimeout свойство, и оно совпадает со значением ExecutionTimeout установить в web.config. Кроме того, тайм-аут, как правило, дают «страница не доступна» сообщение.

Любые предложения приветствуются.

Answer 1

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

Для этого вы не можете дождаться окончания целой строки. Вам нужно переосмыслить свой код, чтобы вместо добавления к строке вы записывали каждое дополнение к выходному потоку. Это имеет дополнительное преимущество, заключающееся в том, что вы гораздо эффективнее создаете свой текстовый файл. Для сохранения содержания в браузере вы можете выписывать что угодно, пока некоторые данные возвращаются для просмотра браузером. Комментарии Html могут работать для этого. Вам также необходимо периодически очищать поток ответов, чтобы ваши данные не сидели на вашем веб-сервере. В противном случае вы можете по-прежнему использовать тайм-аут.

Конечно, настоящим решением является переосмыслить свой дизайн, чтобы ваша операция не занимала 90 секунд плюс в первую очередь. Но пока вы не сможете это сделать, надеюсь, это полезно.

Answer 2

это звучит как тайм-аут. Не могли бы вы попытаться вернуть информацию через View, это, безусловно, ускорит процесс (если возможно).

Answer 3

примерно через минуту, и половина

Там ваша проблема. Это веб-приложение? Полторы минуты - очень долгое время для веб-приложения для ответа на запрос. Достаточно долго, чтобы на самом деле не стоило заниматься различными обманами, чтобы сделать это своего рода работа.

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

Как веб-приложение взаимодействует с процессом? Запускает ли он это или предоставляет информацию для начала процесса? Я бы рекомендовал, чтобы сам процесс обрабатывался чем-то вроде службы Windows или, возможно, консольного приложения. Чем более деактивировано веб-приложение, тем лучше. Теперь, поскольку я ничего не знаю о самом процессе, я делаю несколько предположений о его поведении ...

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

В автономном приложении (Windows Service и др.) Будет просто отслеживаться эта база данных для данных, которые будут обрабатываться в новой очереди. Когда он видит это, он обновляет статус (запуск, обработка и т. Д.) И предоставляет любую соответствующую обратную связь во время процесса (количество обработанных записей и т. Д.) Путем обновления этих данных. Таким образом, автономное приложение и веб-приложение взаимодействуют с одними и теми же данными, но не таким образом, который блокирует поток веб-приложения и предотвращает ответ пользователю.

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

Таким образом, поток не блокируется, пользователь может продолжать взаимодействовать с приложением (если есть что-то, с чем можно взаимодействовать) и т. Д. И вы получаете другие дополнительные преимущества. Например, результаты процесса сохраняются в базе данных и автоматически исторически отслеживаются.

Answer 4

Когда я имел эту ошибку, я был в состоянии решить ее путем добавления в файл Web.config:

<system.web> 
    <httpRuntime executionTimeout="600" maxRequestLength="51200" /> 
</system.web>