Workflows vs. ThreadPool
As I understand it, there is one thread allocated to each workflow instance that is loaded & running. And you can adjust the size of the ThreadPool that these threads are allocated from.
What happens when the number of loaded & running workflows exceeds the number threads available from the pool?
Say I have set the ThreadPool to have 100 threads available and I have 100 workflows running which will never go idle. When that 101st workflow kicks off, what should happen? Will the 101st workflow execute at all? How does the WF runtime handle this?
Thanks,
Matt
My question is how you could have 100 workflows that don't complete and don't hit a point at which they have no more work to do and aren't waiting a significant period of time for some form of reply. Certainly it's possible, and because of the 1 thread per workflow instance, you have to think things thru a little differently.
Thanks Jon. That's what I wanted to know.
Is that something I can have control over with the manual workflow scheduler service? And if so is there a lab that show this?
Thanks,
Matt
With the manual workflow scheduler service you provide the thread that
will execute the workflow, you are free to obtain that thread however
and from wherever like. The workflow runtime just initializes the
workflow and then waits for the host to provide the thread to run it; it
doesn’t refer to the .NET thread pool in anyway.
Khalid Aggag
MSFT
With the DefaultWorkflowSchedulerService you should never allow it to run as many workflow instances as there are threads in the threadpool. The threadpool is a shared resource. If WF is allowed to use every thread that's available you'll starve other components that need threads. For example System.Transactions does some async work using threads from the threadpool (timeout processing for example). WF using System.Transactions. If a workflow is running on everything thread in the threadpool there won't be any threads available when WF calls into System.Transactions. This can result in a deadlock. Exactly how much you need to gate the DefaultWorkflowSchedulerService below the threadpool max count depends on your hardware, scenarios... in other words you'll need to test and see. To gate the DefaultWorkflowSchedulerService use the MaxSimultaneousWorkflow properties (set it when constructing).
Now to answer your first question more specifically (ignoring for a minute the threadpool starvation issue) if you have 100 workflows running and the threadpool has a max of 100 threads and you start a new instance that instance will not run until one of the currently running instances yields it's thread (meaning that it goes idle; this does not mean that it needs to be unloaded from memory, just that it needs to run out of work to do). If none of the instances go idle the new instance will just sit and wait.
Thanks,
Joel West
MS SDE in WF runtime and hosting
This posting is provided "AS IS" with no warranties, and confers no rights
