9 comments

  1. Good stuff. I have had the same frustration with the with the delay activity.

    Joe B

  2. Is there any way to update the delay duration in runtime?
    Currently it seems it can either be initialized from a config file, from the default property or in the initialize event, I want to be able to update the duration after it started running, and it seems very duable in your implementation.

    Itai

  3. Currently modifications of the durations only effect new instances of the workflow. This solves part of your problem. If order to have it also effect running workflows, the activity needs some modification, but not much! So yes, very much do-able.

    It would require two things:
    – Keep the MAX_INTERVAL_DURATION short so the workflow gets reactivated every few days or so (maybe set the ‘check-duration’ as a property on the activity)
    – On reactivate, first refresh the _expiredUtc according to the config-file, before evaluating if the activity can be closed (finished).

    I’ve thought of this before, but had no business requirement (or free time ;)) to cover the required effort.

    robertka

  4. Tks a lot! I really enjoy it! Great job!

    Eduardo Bastos

  5. Yesterday we found out that this activity does not work in a specific situation. When all these criteria are met, you may run into this issue as well:
    – ManualWorkflowScheduler is used
    – The activity is used for delays > 47 days
    – The activity is used in a statemachine-workflow
    – The state that contains the EventDriven-activity for this activity contains other EventDriven-activities as well.

    This issue is that events for the other EventDriven-activities are no longer delivered and the workflow is persisted in a useless (unfixable) state. This behaviour of WF is undocumented, but sadly it does happen.

    BUT! We also found out that MS has finally solved the ‘long-delay’-bug which I mentioned in this article. Although it’s not mentioned in the changelogs, it turns out they fixed it in .NET Framework 3.0 SP1!

    So when using the Configurable Delay activity for sequential workflows, there’s no problem, but when using it for state machines, you need to upgrade to .NET 3.0 SP1 (or 3.5 ofcoz!) and remove the ‘duration splitting’-code from the activity.

    robertka

  6. My state machine workflow (.net 3.0 sp1) is throwing an exception when timer kicks in ..and after that I am having lot of unexpected behavior..like unable to raise events on the same workflow…is there way that I can trace what exception was thrown when my timer (delayactivity) kicked in ? I can see from workflow_instance_status table that exception has occured ..but where do I get the exception details from?

    vasu

  7. Vasu, are you using the ConfigurableDelayActivity (or the SafeDelayActivity)? If so, check my post, just above yours. You can remove all ‘duration-split-up-code’, since it’s no longer nessecary.

    If you’re using the standard delay-activity, remember that when an event of any eventdriven-activities in a state occur, all eventdriven-activities are first unsubscribed. Maybe the unsubscribe-logic of the activities causes problems.

    And it’s always good to configure tracing-settings for WF in your app/web.config. Just enable max. logging, and you’ll be able to troubleshoot most issues.

    Robert te Kaat

  8. Thanks for your help. I am using standard (out of the box) delay activity.
    Let me try enable logging & see what information i am going to get.
    But I have a question. I can surely use your help.

    In my scenario, my workflow would trigger something based on a timer(delay activity) but doesn’t change the state. If events are going to be unsubscribed, do I need to subscribe again (If so , How?)as I have events that could be fired after this timer event? or Should I set the state to the same state again (would that automatically subscribe everything back again?)?

    Please let me know .

    Thanks in advance & looking into my issue description.

    Vasu

  9. Any eventdriven inside a State-activity MUST set the state. Either to the same state or to a different state. If you don’t, you end up with a workflow that does not accept events (from either a passed timer duration or incoming event (eg: HandleExternalEvent)) and is therefore completely useless.
    And make sure the fault-/cancellation-/compensation-handler call SetState as well!

    robertka

Comments are closed.