When does the Workflow runitme decides to abort a workflow?

Question

Hi,

Currently we are running a proof of concept where we need to do High volume Workflow processing.

What we see happening is that the workflow engine is running perfectly. But suddenly we see that with no tracable reasons (in eventlogs, transaction logs, etc) we get workflows aborted. This happens after an hour of so running under high load. (Hosting in IIS with 4 worker processes, using default SQL tracking, SQL persistence and manual workflow scheduler) we run this on a quad processor machine.

 

We see no memory pressure (at least 1.5 GB still available) we see perfect perf graphs if it comes to numer of threads, processor (arround 70%) , context swithches, etc.

 

While digging through the documentation there is a remark that the workflow engine can decide to abort a workflow in extreme cases. Quote from MSDN :

A workflow instance is considered to be aborted when the workflow runtime engine throws away the in-memory instance. The host applications can abort the workflow instance by calling WorkflowInstance.Abort(). Aborted workflow instances can be resumed from their last persistence point by calling WorkflowInstance.Resume(). Aborting a workflow instance is used in extreme situations where an application decides to discard all the work that was done from the last persistence point until WorkflowInstance.Abort() is called

Can someone give more information on what is considdered as an extreme situation, or is this refering to the application I am writing? I am not aborting in code, that is for sure.

 

Does someone have some hints or tips to get to the bottom of this problem and how I can pinpoint the problem?

 

Thanks allot

Marcel

Answer 1

I think I just found why the workflow aborts ....

 

We use the SQLTracking service. This service has a Type Table where it can only store 32K type entries since the ID is of the type int

Now we are using Xoml Based workflows and this is where things break

In the tracking service there will be an insert for every workflow type, but when this is a Xoml based workflow this is the workflowInstanceID.

This results in the fact that I only can have 32K workflows stored in the tracking database?!?

 

I used Reflector to see what is done in the SQLTracking code and there you see the fact that a instanceID is used in stead of the type.

I also changed the implementation to a code version in stead of a Xoml based version of the workflow and now I can run it without a problem....

 

Can someone from MS confirm or deny that this is causing the problem?

 

Thanks allot,

Marcel

Answer 2

Refer to http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1532804&SiteID=1 for detailed answer.

 

It is confirmed that there is a limition of 32K workflow types supported by the SqlTrackingService and that each xaml instance causes a new type to be created.

Answer 3

Sumit,

This posting is no longer availible.  Can you post the new location? 

---

- Rashad Rivera www.omegusprime.com