« Managed Custom Action (Wix) Error  
 

Biztalk Direct Binding Messaging Error

Biztalk Direct Binding Messaging error
A few months ago I worked on a medium-size Biztalk project. I’ll depict in a few words the big picture of the application architecture in order to understand the context. The application backend was based entirely on Biztalk. The reason was all the Biztalk “poetry”: reliability, scalability, availability, asynchronous processing… the rich customer ready to pay for a Biztalk solution. The backend was designed to have two layers: one that exposes common and granular services specific to the business domain, the other one was thought to be specific to the applications that will consume the services. The services layer has an orchestration for each service it exposes.
The communication between the two layers was implemented with the Direct Binding mechanism to have a low coupling between layers. So the application specific layer is publishing a message into the MessageBox and the services layer consumes the message basing on its orchestrations subscriptions. The response path was designed in the same way.
The other thing that should be mentioned is that our team was involved only in the development of the services layer.
We deployed the application in the production environment and after a while we started to receive from time to time the following strange and meaningless error in the event viewer:

Event Type: Error
Event Source: XLANG/s
Event Category: None
Event ID: 10008
Date: 27/10/2007
Time: 04:33:29
User: N/A
Computer: Computer
Description:
Uncaught exception (see the ‘inner exception’ below) has suspended an instance of service ‘ServiceLayer.Service1(92cac9e7-dbe2-d8dd-515b-6805d86d001d)’.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 5789b48b-6297-452f-8b41-ff9a6b1090ec
Shape name: Send Service1Msg
ShapeId: 82d935e6-6c3d-4f4e-86e0-1c8ddb679ea3
Exception thrown from: segment 1, progress 59
Inner exception: Exception occurred when persisting state to the database.

Exception type: PersistenceException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Void Commit()
The following is a stack trace that identifies the location where the exception occured

at Microsoft.BizTalk.XLANGs.BTXEngine.BTXXlangStore.Commit()
at Microsoft.XLANGs.Core.Service.Persist(Boolean dehydrate, Context ctx, Boolean idleRequired, Boolean finalPersist, Boolean bypassCommit, Boolean terminate)
at Microsoft.XLANGs.Core.LongRunningTransaction.PendingCommit(Boolean ignore, XMessage msg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.SendMessage(Int32 iOperation, XLANGMessage msg, Correlation[] initCorrelations, Correlation[] followCorrelations, Context cxt, Segment seg, ActivityFlags flags)
at ServiceLayer.Service1.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
Additional error information:

A batch item failed persistence Item-ID d3057a06-4e67-45b8-99ce-4c2b4e3c79ac OperationType MAIO_CommitBatch Status -1061151998 ErrorInfo The published message could not be routed because no subscribers were found. .

Exception type: PersistenceItemException
Additional error information:

Failed to publish (send) a message in the batch. This is usually because there is no one expecting to receive this message. The error was The published message could not be routed because no subscribers were found. with status -1061151998.

Exception type: PublishMessageException

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

After some investigation we observed that the issue is manifesting under high load of the services layer. In that scenario the service response time increased considerable so we decided to ask the guys that implemented the specific application layer how they deal with such a scenario. We found out that they had implemented a timeout mechanism that signal the front-end application about the timeout and terminate the orchestration.
It was clear for us that the problem has something to do with the Direct Binding and with the fact that the consumer orchestration is closed before receiving its response. The service orchestration publishes a message that doesn’t have any subscriber because the consumer orchestration is terminated meanwhile.
In order to reproduce this behavior we created a test application with two orchestrations: a consumer orchestration and a service orchestration. The consumer application publishes a message and waits for the response for a given time… if the time expires it will terminate. The service orchestration has some delay activity that will let enough time to the consumer to terminate before sending the response. The same error is received with the test application.
In conclusion, you should pay attention and not terminate the consumer orchestrations that are involved into Direct Binding communication pattern before receiving the response, otherwise the administration work will become interesting or the application will remain in an inconsistent state.

October 14th, 2009 | Category: .Net Technologies

267 comments to Biztalk Direct Binding Messaging Error

1 2 3 ... 6
1 2 3 ... 6

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comment Spam Protection by WP-SpamFree