locked
Problem with Load Balanced Windows Workflow Application RRS feed

  • Question

  • I'm using windows workflow foundation in a asp.net web service application. Everything works fine until network load balancing is activated and requests during a workflow are balanced to different runtime hosts (iis). The workflow is used for a step by step checkout process. The failure scenario goes like this:

    1. The workflow is started on host A and is in the initial state. A state transition occurs to State2. The state is persisted by the SQLPersistenceService.
    2. The Workflow state is correctly loaded on host B. A state transition occurs to State3. The state is persisted by the SQLPersistenceService.
    3. Host A queries the StateMachineWorkflowInstance for the current state. The state is State2 again but should be State3.


    I use the SQLPersistenceService with UnloadOnIdle to true.

    To debug the problem I queried the workflow state step by step with a simple windows app during the checkout process without NLB activated. From step 2 the current workflwo state is always State2.

    Any ideas how it can happen that the current state is not persisted correctly?

    Are there some things that I have to take into account when using wf with multiple hosts?

    Thanks in advance,
    Marco

    Thursday, April 3, 2008 6:37 AM

Answers

All replies

  • Do you have any delay activies in the workflow? This could cause multiple runtimes to load same instance multiple times if you do not use locking with persistence provider.

    Thursday, April 3, 2008 3:58 PM
  • Hi Dinesh
    No, I have no delay activities.

    Marco
    Friday, April 4, 2008 6:27 AM
  • have you validated that the workflow moved to state 3?  if you query the state from host b, does it also report state 2, or does it think the wf is at state 3? 

     

    how long does the processing take in your workflows when each event occurs?  Are you waiting long enough in your test application to ensure that the transition and persistence have completed?

     

    Matt

    Friday, April 4, 2008 6:48 PM
  • Hi Matt

     

    -- have you validated that the workflow moved to state 3? 

    Yes I validated it with the StateMachineWorkflowInstance

     

    --if you query the state from host b, does it also report state 2, or does it think the wf is at state 3? 

    If I query it from host b, it reports state 3.

     

    --how long does the processing take in your workflows when each event occurs? 

    Processing takes just a few seconds. I waited several minutes, the state stays at state 2

     

    Marco

     

     

    Sunday, April 6, 2008 10:23 AM
  • When you query on host A, are you using an existing instance of the StateMachineWorkflowInstance class, or creating a new one?  I'd make sure to use a new one just in case there is a caching issue.

     

    matt

     

    Monday, April 7, 2008 12:33 PM
  • Hi Matt

    I'm always using a fresh instance.

     

    Marco

     

    Saturday, April 12, 2008 8:41 AM
  • Try this as a test:

     

    On host A, when you expect it to be in state 3, call the GetWorkflow method on the workflowruntime to get the workflow. 

      An interesting side test would be to either a) wathc with SQL profiler for the call to load this, or b) call GetLoadWorkflows and see if your instance is in the collection.  Perhaps the runtime is not unloading it. 

     

    After you get the instance back from the runtime, call the GetWorkflowQueueData method on the instance.  Take a look at the subscribed activity name(s) on each queue to find out who is listening.  The one you will be most interested in is the one named "SetStateQueue". 

     

    Let me know if a) your workflow was in the runtime already, and therefore didn't have to be loaded from the persistence store and what activity name you see subscribed to the SetStateQueue queue. 

     

    Matt

     

    • Proposed as answer by Michael Wasser Wednesday, February 11, 2009 11:46 PM
    Saturday, April 12, 2008 8:22 PM
  • Hi Matt
    Thanks for your debugging tips. I will do that as soon I'm back to this problem.

    Marco
    Tuesday, April 22, 2008 7:54 AM