Использование рабочего процесса Windows в приложении ASP.NET AJAX - PullRequest
Новая
       12

Использование рабочего процесса Windows в приложении ASP.NET AJAX

1 голос
/ 21 марта 2009

Я использую Windows Workflow как часть библиотеки классов в приложении ASP.NET. Я прочитал все предложения о настройке WWF в ASP.NET и использовании ManualWorkflowSchedulerservice, однако я не уверен, имеет ли это смысл для моего приложения.

Все мои рабочие процессы последовательны, без сохранения; они огонь и забудь. Клиент делает запрос и возвращается позже, чтобы увидеть результаты (или ждет в приложении). До сих пор я использовал класс веб-службы AJAX для запуска работы. 

function DoWebserviceJob()
{
   MywebService.DoJob(onComplete, onFailed);
}

[WebMethod]
public DoJob()
{
   //code from library
}

Если бы клиент все еще был рядом, он получил бы уведомление, если бы не было в порядке. Теперь я использую WWF вместо кодирования прямо из библиотеки. Я знаю, что это работает (так как я это сделал), но мне интересно, есть ли какие-то побочные эффекты, о которых я не знаю, или другие проблемы. Мой новый код выглядит так: 

[WebMethod]
public DoJob()
{
     WorkflowRuntime runtime = Application["RUNTIME"] as WorkflowRuntime;
     MyWorkflowManager.DoJob(runtime);
}

Моя библиотека классов: 

public void DoJob(WorkflowRuntime runtime)
{
   WorkflowInstance instance = runtime.CreateWorkflow(typeof(MyWorkflow));
   instance.Start();
}

Это немного упрощено, но общий процесс здесь. Это работает отлично прямо сейчас, есть какие-то вопросы, которые я должен быть обеспокоен? Если это потоки (что, кажется, является наиболее цитируемой проблемой), это не то же самое, что запуск веб-службы в другом потоке?

1 Ответ

3 голосов
/ 29 марта 2009

Трудно дать вам хороший ответ, так как много неизвестных, но я все равно покажу его.

Наиболее часто встречающаяся проблема с ASP.NET и WF заключается в том, что оба используют ThreadPool и не знают друг друга. Эта проблема в основном зависит от вашего ASP.NET-сайта. WF по умолчанию использует только несколько потоков в ThreadPool (4 на процесс для выполнения рабочих процессов и один для выполнения). Проблема обычно решается с помощью ручного планировщика WF, так как WF затем использует основной поток, то есть тот, который используется ASP.NET. Теперь это может быть хорошо или плохо в зависимости от ваших потребностей. Прежде всего, размер ThreadPool рос и теперь составляет до 250 потоков на процесс, поэтому вряд ли проблема с ThreadPool будет возникать, если только он не загружен. Недостатком использования ручного планировщика является то, что все запросы, то есть instance.Start (), становятся синхронными. Если вам нужно что-то из рабочего процесса для завершения запроса, но если он запущен и забыли, ваш запрос ASP.NET теперь ожидает завершения рабочего процесса или достижения какого-то состояния простоя. Так что в некоторых случаях вам лучше будет использовать планировщик по умолчанию в приложении ASP.NET, все зависит от того, что вы делаете, и нагрузки на сервер.

Следует иметь в виду, что IIS перезапустит AppDomain через определенное время, по-моему, 25 часов по умолчанию или число запросов. Когда это происходит, среда выполнения WF уничтожается и, как я полагаю, при следующем запросе воссоздается в другом домене приложений. Если вы не используете постоянство, все ваши рабочие процессы будут потеряны, а существующие рабочие процессы будут прерваны. В зависимости от того, сколько времени занимает рабочий процесс, это может быть проблемой, а может и не быть, трудно сказать с моей стороны.

...