Workflow Services Limitations: Part 5 – A Couple of Updates

May 14, 2008

tags: ,
no comments

In the previous posts in this series, we have observed a couple of weird behaviors around Workflow Services, specifically:

Both of these behaviors have been confirmed.

The suggested workaround for the one-way issue is to release the WCF thread on the service side (by using ThreadPool.QueueUserWorkItem or any similar API).

The race condition scenario is more complicated that I thought.  The reason for the problem is that when the WCF message reaches the workflow, the WorkflowOperationInvoker ultimately uses WorkflowInstance.EnqueueItemOnIdle to enqueue the pending work.  This works perfectly if there’s no idle point between the send activity and the receive activity:

image

However, if a delay activity is introduced, then the delay potentially causes the workflow to idle before the receive activity has created a queue for the incoming message.  As a result, the message is swallowed.

The workaround, as I suggested in the original post, is to ensure the receive activity is scheduled before the workflow goes idle.  The parallel paradigm with the receive activity on the left-most branch and the rest of the work in the other branches will ensure this happens at runtime:

image

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*