problem with BizTalk Scheduled Task Adapter 2.0

Feb 24, 2010 at 2:01 PM

On our current project within OS we have a problem with BizTalk and Orchestrations not firing/starting/working in a way that we can predict or expect.

We are using the BizTalk Scheduled Task Adapter 2.0 by Greg Forsythe downloaded from CodePlex to schedule an Orchestration to start every 3 minutes. There are several other Orchestrations setup to start in the same way.

One Orchestration in particular has additional Trace information in an attempt to try and figure out what is going on. All of the Orchestrations are behaving in a similar way with their failure to execute like we would expect. 

This Orchestration, as its first step, will Receive the Trigger message and then proceed to do the work in the rest of the Orchestration. The Orchestration does create a trace log entry at the start (logged at 11:05:00 am) and another trace log entry at the end (logged at 11:05:01 am). This is all good and well as in this time frame there was no work to process. However, the next execution of this was at: 11:25:00 am and then finished at 11:25:02, again with no work to do.

What we cannot understand, nor determine is why there is a 20 minute gap between executions of the Orchestration. Especially since a reboot of the server/BizTalk service causes the problem to disappear and then reappear a few hours or execution cycles later.

I have a Debug Trace obtained via DebugView which shows all of the output we would expect, but not as regularly as we would like. Thus far, I have read through a few hours of the trace after a BizTalk service re-start and it all appears good and well with the Orchestration starting every 3-5 minutes depending on the work load. This is entirely acceptable behaviour, taking longer, 20+ minutes per execution cycle however is not.

Can anyone suggest a way forward for a viable alternative for scheduling the Orchestrations to start, or how this problem can be fixed?

Jun 4, 2010 at 3:58 PM

I had a similar issue but it is not related to the task schedule adapter. After removing suspended messages,  the adapter works correctly.