Freigeben über


ASP.NET and DefaultWorkflowSchedulerService

QUESTION: Can I use DefaultWorkflowSchedulerService instead of ManualWorkflowSchedulerService in my IIS hosted WorkflowRuntime?

ANSWER: Do so at your own risk. It's like swimming in an unguarded pool or skydiving ...

Using the DefaultWorkflowSchedulerService in an IIS host (specifically ASP.NET) is one of those good/bad scenarios depending on point of view. Windows Workflow Foundation (WF) has no qualms about using the DefaultWorkflowSchedulerService in an ASP.NET hosted scenario and everything will work just fine from a WF point of view. The problem is that ASP.NET does NOT like people using up all its threads.

Our ManualWorkflowSchedulerService was written specifically for the ASP.NET scenario to make sure that we were running on the minimal number of threads. The call to RunWorkflow is an explicit "gifting" of the current thread (the request thread in the IIS case) to run as much of a specific workflow instance as possible. When you introduce the DefaultWorkflowSchedulerService you are, by default, allowing as many as 4 threads to run workflow instances.

Is that a bad thing? In most cases, no. Don't quote me on these numbers, but .NET supports something like 25 threads per processor per Process. If you are doing anything with Transactions, then at least one of those threads needs to be "available" to avoid deadlock in some cases. The number of threads ASP.NET requires depends on the situation - if you are running a single web service in an isolated AppPool then I can't imagine ever running into an issue.

So, what's the "official word" - the statement that covers everyone's butt and will hopefully steer users to a design that is free from danger?  

First, examine your scenario.  Ask yourself why you need to be doing the processing in the background (non-request thread)? Is all processing tied to a request? Does the processing take very long? Is new processing ever driven by a "delay" in the workflow or some event not tied to an inbound request?

If you are doing a lot of processing then it is often better to model this as a windows service. Using Windows Communication Foundation (WCF) you can directly expose your windows service as a consumable web service. Alternately you can use WCF or .NET Remoting (last generation technology at this point) to communicate between your current web service and your windows service.

If you aren't doing much processing and it is all tied to the request, then consider using the ManualScheduler. While this will add additional latency to your responses, it can be considered a constant value as opposed to the unpredictable response times you'll see when you've got an unknown number of active workflow instances vying for processor time.

In general, try to avoid using the DefaultWorkflowSchedulerService in ASP.NET/IIS. If you do use it, use it with caution and expect that there may be a few unknown problems which pop up during stress. There is always an alternate design and in general the tradeoffs will be maintainability/complexity versus request/response speed versus stability under stress.

Comments

  • Anonymous
    April 25, 2006
    Thanks!
  • Anonymous
    April 26, 2006
    I have a workflow with 3 activities
    1) Create Customer
    2) Create Education history
    3) Create Job Histroy

    I created new workflow instance and completed step1.
    Next time, depending on workflow activity I need to show either screen1 or screen2.
    FOr that purpose, I want to open workflow and want to know whether "Create Education history" is done or not. How do I know that?
  • Anonymous
    April 28, 2006
    I really like what the on10 guys did with the on10 website. The login UI is the best I've seen and I...
  • Anonymous
    May 02, 2006
    If you are using a state machine workflow in ASP.NET you need to use the ManualSchedulerService. ...
  • Anonymous
    May 19, 2006
    The comment has been removed
  • Anonymous
    May 23, 2006
    Hello,

    I'm very interested in exploring the following paragraph in your blog:

    "If you are doing a lot of processing then it is often better to model this as a windows service.  Using Windows Communication Foundation (WCF) you can directly expose your windows service as a consumable web service.  Alternately you can use WCF or .NET Remoting (last generation technology at this point) to communicate between your current web service and your windows service."

    Our requirement is to build scalable workflow apps using an SOA model.  We want to be able run many instances of long-running workflows of different types.  The workflows will generate human tasks which will be rendered and actioned through our existing user interface.  We currently have a BizTalk implementation in which the worklfow map is encoded.  We use web services to communicate between the workflow and the interface code.  We are looking to WF to make our workflow definition more flexible and easier to develop.  So far I'm very impressed with WF and eager to take advantage of it.  I have been researching WF hosting and communication options for the past week and am trying to figure out the best model to follow.  Initially, I was looking at running my workflow in a web service (to follow loosely our current model), but the threading and runtime issues seem to complicate things.

    Based on the paragraph I quoted from your blog, you mention the ability to run the workflow from a windows service yet expose it via a web service.  This seems like a more robust model.  Do you have any tips or code samples on how I would go about this?  Based on my requirements do you agree this is a good direction?  Looking ahead I may want to scale the workflow across a server farm, but for the time being I'm happy to have multiple web application servers communicating with a single server that hosts the workflow.

    In any case,  I'd really value your opinion.  I have gathered a lot of useful information from your blog, so thank you very much.

    All the best

    Steve
  • Anonymous
    May 24, 2006
    The comment has been removed
  • Anonymous
    May 24, 2006
    Thank you very much for taking the time to reply.  You've given me a great deal of information to absorb and ideas to try out.  I will take what you've given me and run with it for a few days and see what I can put together.   I'll probably take you up on your offer to help with further questions.  In any case I'll let you know when I have something solid working and will share my findings.

    Thanks again!
  • Anonymous
    July 10, 2006
    If you're using state machine workflows in a ASP.NET app, make sure you use the ManualWorkflowSchedulerService...
  • Anonymous
    August 13, 2006
    WF resources
  • Anonymous
    December 15, 2006
    Very interesting article which addresses several issues I currently need to solve.I'm planning on using WCF for my services and use WF for the actual implementation of the service-logic.I created a service-behavior to add an extension to the servicehost which loads a workflow runtime. I can now add this behavior either by configuring it in the application config or by using an attribute on the service implementation class (I'll add this behavior+code to my blog soon).However, I use the extension as a container for my workflow-runtime: when the extension is created, it also creates the WF-runtime and keeps a hold of it in a private field. Since this is all executed within IIS, I also get the drawbacks from running WF in IIS. I could ofcourse self-host my WCF-service in a Windows-service, but then I loose all the advantages I get from IIS (queing, buffering, apppool-recycling, etc).  Therefore I'm thinking of modifying the extension to retrieve a reference to the WF-runtime from a running windows-service instead. This way the extension still works, my WCF-service is still host-agnostic and I'm no longer limited by the threading-issues that were introduced by IIS.I'm not sure if this is all going to work or if there's anything I;ve overlooked? So if anyone has some tips, just let me know!
  • Anonymous
    February 09, 2007
    i need some help here.. I am using Sequential workflow in an asp.net page and I use ManualWorkflowSchedulerService. At one of the states I have included a delay activity. My code gets to the point where it initializes the delay event timer and then nothing happens. It is like the delay timer if off on its own thread and is lost to oblivion with out nothing happening after that in that workflow instance. is there some known issue with ASP.net WWF and this delay activity class, or do I need some serious reading ??
  • Anonymous
    June 08, 2009
    PingBack from http://toenailfungusite.info/story.php?id=8784
  • Anonymous
    June 09, 2009
    PingBack from http://quickdietsite.info/story.php?id=13433
  • Anonymous
    June 16, 2009
    PingBack from http://fixmycrediteasily.info/story.php?id=1426
  • Anonymous
    June 17, 2009
    PingBack from http://pooltoysite.info/story.php?id=6177