Geeks With Blogs
Simon Emmanuel RIVAS

Never overlook any property, this is the conclusion I have come to after diagnosing a tricky bug…Here is what happened.


I had an orchestration orchA that consumed messages submitted by a one-Way HTTP receive port, which routed a transformed copy of the message to another orchestration orchB. When an error occurred in orchB, an ESB fault was generated with the input message attached to it and the fault was then sent to the ESB Exception Db. A classical error handling scenario…

When resubmitting the message from the ESB portal, the resubmission timed out after 1min, leaving me with this message:


Investigating the error

When I looked at the eventlog on both BizTalk and ESB portal servers, I was happy to discover that there was nothing to see: not an error, not a warning, not even an information entry that could even remotely be related to the problem. Nothing in the message box either (suspended or not).

It looked as if the ESB Portal was not able to contact BizTalk, which was weird since resubmitting messages for other processes worked just fine. So I activated WCF traces on the BizTalk server and discovered that the ESB portal did contact the BizTalk Server, even managed to send the whole message and then aborted the connection after waiting for 1 min:


So my feeling was that the portal worked just fine and that BizTalk was holding the connection.

Attaching the Visual Studio debugger to the receiving host and setting a breakpoint in the ESB receive pipeline component (ExceptionResoving.Pipelines.DisAssembler) revealed that for some reason, BizTalk was indefinitely executing the pipeline component in loop. That explained the fact that BizTalk was holding the connection!

The message body being OK (I made sure of that by replacing the message content of another fault and then successfully resubmitting it), it had to be one (or several) of the attached properties that caused this behavior. After testing each of them (by deleting them one by one and resubmitting the message each time), I finally isolated the faulty property: BTS.ActionOnFailure. Without it, I was able to resubmit the message successfully.

If we take a look at this page, we can see that 0, which was the value of this property, “Indicates that the messaging engine should not automatically suspend the engine” when there is a failure in the receive pipeline.


It kind of makes sense, though I’m not sure what sense exactly: I understand it is the reason why BizTalk kept looping without suspending the message, but it isn’t clear why the pipeline was executed in loop. Not to mention the fact that I couldn’t find any error during the processing of the message by the pipeline!

Anyway, even though the BTS.ActionOnFailure property was causing the failure, which remains to be clarified, I think it was merely a consequence of the way the orchA orchestration was built: in this orchestration, all of the source message property bag was copied to the output message (the one consumed by orchB) instead of just the properties required for later processing. In my opinion, the problem lies in the fact that the property bag contained some properties related to the HTTP receive port and receive adapter, which probably disturbed the messaging engine… If you have any opinion about it, please let me know!

Posted on Tuesday, December 3, 2013 10:27 AM BizTalk , ESB , Timeout , Property Bag , HTTP | Back to top

Comments on this post: ESB times out when resubmitting a message

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © S.E.R. | Powered by: