|
Home > Archive > BizTalk Server General > March 2006 > BizTalk 2004 :: Orchestration timeout not working
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
BizTalk 2004 :: Orchestration timeout not working
|
|
|
|
Hello,
I've encountered a very strange problem with my orchestration's timeout properties.
I have a request-response operation via SOAP. SOAP has a timeout of 120 seconds.
My orchestration has a base Long Running Transaction of 70 seconds
Inside the orchestration I have scope shape A (Long Running Transaction of
65 seconds) with a catch block to send error responses back to the SOAP port
in case of errors or timeouts.
Inside scope A I have an Atomic scope B (retry = false) with a timeout of
60 seconds.
In scope B I am calling rules, a .net component and then another set of rules.
The error is occuring because of a bug in the .net component which is causing
the component to hang. To catch it, scope B should timeout within 65 seconds
and cascade to the catch block of scope A. I am in fact reaching the catch
block, but why is it taking 220 seconds?
The result is my error message is never getting back to the user because
the SOAP timeout of 120 seconds has long since been triggered.
I could use some help.
BA
http://biztalkia.blogspot.com/
| |
| Tomas Restrepo \(MVP\) 2006-03-25, 11:37 am |
| BA,
> Hello,
>
> I've encountered a very strange problem with my orchestration's timeout
> properties.
>
> I have a request-response operation via SOAP. SOAP has a timeout of 120
> seconds.
>
> My orchestration has a base Long Running Transaction of 70 seconds
>
> Inside the orchestration I have scope shape A (Long Running Transaction of
> 65 seconds) with a catch block to send error responses back to the SOAP
> port in case of errors or timeouts.
>
> Inside scope A I have an Atomic scope B (retry = false) with a timeout of
> 60 seconds.
>
> In scope B I am calling rules, a .net component and then another set of
> rules.
> The error is occuring because of a bug in the .net component which is
> causing
> the component to hang. To catch it, scope B should timeout within 65
> seconds
> and cascade to the catch block of scope A. I am in fact reaching the catch
> block, but why is it taking 220 seconds?
I *think* that the timeout on atomic transaction scopes (and possibly on
long running ones, as well) is not meant to be hard. In other words, it does
not mean that it will "break" processing if the timeout is exceeded, but
rather means that if execution takes longer than the timeout time, the
transaction will abort (heck, that's just what it means for DTC
transactions, so it would make sense).
You might have to find a way of doing the hard break at the code level
itself, possibly by wrapping the problematic compoonent inside another one
that enforces it (should be fairly trivial to do so by simply starting the
call to the real component async and then doing a wait on an event or some
other control mechanism with a timeout).
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
|
|
Hey Tomas,
I've done some more research and yes, the transaction doesnt do a hard break
on the step being executed.
This has implications. I'd always worked with the assumption that a 60 second
timeout would last 60 seconds.
This post also helped explain it:
http://www.traceofthought.net/Perma...e5e1ec29b3.aspx
I wish that a derivative of the and/or functionality with branching in BizTalk
2000/2 was in 2004. It would be nice to run my .net component inside of
a branch and have a delay in another branch, whichever one finishes first
dictates the next processing.
There are options within the orchestration for situations when you are using
a dll which you cant modify, as you mentioned a code update would be easiest.
BA
http://biztalkia.blogspot.com/
> BA,
>
> I *think* that the timeout on atomic transaction scopes (and possibly
> on long running ones, as well) is not meant to be hard. In other
> words, it does not mean that it will "break" processing if the timeout
> is exceeded, but rather means that if execution takes longer than the
> timeout time, the transaction will abort (heck, that's just what it
> means for DTC transactions, so it would make sense).
>
> You might have to find a way of doing the hard break at the code level
> itself, possibly by wrapping the problematic compoonent inside another
> one that enforces it (should be fairly trivial to do so by simply
> starting the call to the real component async and then doing a wait on
> an event or some other control mechanism with a timeout).
>
|
|
|
|
|