Konstantin Vyaznikov

Hi,

Is it true that event WorkflowIdled can be obtained after workflow completes At least that's what I observe.

Thanks,

Konstantin.



Re: Windows Workflow Foundation WorkflowIdled event from runtime

umarkstafford

No other event related to the workflow should be able to be thrown after the workflow is completed. I'd imagine that if you look into this more, you'll find the answer. If you don't, ping me back and I'll see if I can reproduce.

Mark





Re: Windows Workflow Foundation WorkflowIdled event from runtime

Konstantin Vyaznikov

Ok.

Maybe I phrased it not that much right. I will try one more time.

Let's imagine I have a handler for WorkflowIdled event and within this handler, I try to ask for:

wfInstance.GetWorkflowNextTimerExpiration();

If I have an activity, which makes very short task, let's say my custom activity, which returns ActivityExecutionStatus.Executing, (this triggers WorkflowIdled event, right ), does something very short and completes. For example can be a delay activity with short waiting time.

I observe that under high load and on slow computer (VPC for ex), sometimes I get exception from GetWorkflowNextTimerExpiration() within WorkflowIdled event handler. The exception tells that workflow was not found in persistence store.

From the trace log which I have, I see that workflow really completed successfully and the request to GetWorkflowNextTimerExpiration() happens after completion. I think that could happen if WorkflowIdled event was fired when workflow was alive, but in asynchronous way, thus call to GetWorkflowNextTimerExpiration happens after the completion of workflow, because handler for WorkflowIdled and execution of workflow runs on different threads and race condition happens.

Does it happen as I think

I can mock-up some simple stuff, demonstrating the problem, but it requires stress load to reproduce such behaviour.

Thanks,

Konstantin.





Re: Windows Workflow Foundation WorkflowIdled event from runtime

Mark Stafford

Ah... with that explanation, I can say that we've seen a similar behavior raising events. We mocked up a workflow that went through a series of states, listening for various events to be raised. What we found was that the events could be raised more rapidly from the host than the workflow could respond. For example, we raise one event that should be listened for, notification sent back to the host, and then the workflow would transition into a new state. We had a problem where we would raise a second event, but the workflow couldn't handle that event because it hadn't yet transitioned.

What you're seeing is likely the time differential that it takes to communicate over the ExternalDataExchangeService bridge. Our conclusion was that this isn't an error state, and it's not really a problem - it just needs to be noted. If you really need to know what the context was at that instant, for example, you'd want to include that in the payload you send across the divide. We are working on taking the same thing into account.

Does -that- make sense Is it the same behavior you have

Mark





Re: Windows Workflow Foundation WorkflowIdled event from runtime

Konstantin Vyaznikov

Hi Mark,

Thanks for sharing info. All you said makes sense and actually the behaviour which I experience is good for me. I only worried that I do something wrong and asked just in case. In my situation, I treat exceptions of such kind as indication that workflow completed.

Thanks again for your time.

Konstantin.