Лучший способ запустить фоновое задание в веб-приложении ASP.Net и получить обратную связь? - PullRequest
4 голосов
/ 24 декабря 2008

Я думаю о следующем подходе, но не уверен, что это лучший выход:

step1 (на стороне сервера): класс TaskMangaer создает новый поток и запускает задачу.
шаг 2 (на стороне сервера): сохраните ссылку на объект taskManager в кэш для дальнейшего использования.
шаг 3 (на стороне клиента): используйте периодический Ajax-вызов для проверки состояния задачи.

По сути, намерение состоит в том, чтобы создать среду для выполнения фоновой задачи (примерно 5 минут) и регулярно предоставлять обратную связь в веб-интерфейсе для определения процента выполненной задачи.

Есть ли полезный способ обойти это или любое существующее API asp.net, которое будет полезно?

Редактировать 1 #: Я хочу запустить задачу в приложении с приложением.

Редактировать 2 #: Похоже, реализация значка при переполнении стека также использует кэш для отслеживания фоновой задачи. http://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/

Ответы [ 4 ]

1 голос
/ 24 декабря 2008

Один из подходов для этого - использовать состояние приложения. Когда вы создаете рабочий поток, передайте ему сгенерированный вами идентификатор запроса и верните его клиенту. Затем клиент передаст этот идентификатор запроса обратно на сервер в своих вызовах AJAX. Затем сервер будет получать статус, используя идентификатор запроса из состояния приложения. (Рабочий поток будет обновлять состояние приложения в зависимости от его состояния).

1 голос
/ 24 декабря 2008

Я думаю, что проблема с сохранением результата в кеше заключается в том, что ASP.NET может очистить эту запись в кэше для других целей (например, если у нее недостаточно памяти, если она раздражительна и т. Д.). Что-то, что подается из кэша, должно быть чем-то, что вы можете воссоздать по требованию, если оно не найдено в кэше, среда выполнения ASP.NET может свободно выгружать записи кэша, когда захочет.

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

Можете ли вы подтвердить, что это задача, которая займет 5 минут и потребует отдельного потока все это время? Само по себе это проблема производительности, вы сможете поддерживать ограниченное количество таких запросов, если для каждого так долго требуется собственный поток. Только если это приемлемо, я позволю заданию так долго продвигаться.

Если для этих задач вполне приемлемо закрепить поток, то я бы просто сохранил результат в глобальном словаре процесса. Ключ словаря будет соответствовать клиентскому запросу / серии обратных вызовов AJAX. Ключ также должен включать идентификатор пользователя, если безопасность вообще важна.

Если вам нужно масштабировать до нескольких пользователей, то я думаю, что вам нужно разбить задачу на асинхронные этапы, и в этом случае я бы, вероятно, использовал таблицу БД для хранения результатов (опять-таки ключ по запросу / пользователю ).

1 голос
/ 24 декабря 2008

Microsoft Message Queuing была создана для сценариев, подобных тому, который вы пытаетесь решить: http://www.microsoft.com/windowsserver2003/technologies/msmq/default.mspx Windows Communicatio Foundation также поддерживает очереди сообщений. Надеюсь, это поможет.

Thomas

0 голосов
/ 24 декабря 2008

Я видел подход к подобной проблеме где-то. Решение было что-то вроде:

  1. Запустите фоновое задание на сервере. Немедленно вернитесь с URL-адресом к результату.
  2. Пока результат не опубликован, этот URL будет возвращать 404.
  3. Клиент периодически проверяет этот URL.
  4. Клиент читает результаты, когда они наконец отправлены.

URL будет что-то вроде http://mysite/myresults/cffc6c30-d1c2-11dd-ad8b-0800200c9a66. Лучший формат документа, вероятно, JSON.

Если важна обратная связь о ходе работы, измените документ, чтобы он также содержал информацию о состоянии (в процессе / завершение) и ходе (42%).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...