Question

I have an Orchestration with a Direct Bound Logical port. Lets call it “O1”
O1 subscribes to message type “A” (specified in the filter property of the Receive Port)

When O1 receives a message of type “A” it waits for some user input before completing. (Some correlation in play here)

So far so good…

I have a second orchestration, “O2” that constructs and pushes a message of type “A” to the message box.

When this happens, I get many instances of O1 starting up.
All I can think of is that as long as an instance of O1 is in existence, the message is still available on the message box for subscribers to consume. So, I will I’m getting instances of the orchestration being created constantly.

When a message is being processed by an Orchestration does it remain in the Message Box until completion?

Would be very grateful is someone can explain what’s going on and what I’m missing!

Answer 1

When a message is being processed by an Orchestration does it remain in the Message Box until completion?

No. Actually the message is in the message box, but it is marked as active. So no other process will use it. Maybe O1 is constructing a messages of type A so it reactivate itself.

Look at this Tips And Tricks article:

Now for the fun part. A common pitfall with Direct-Bound ports, particularly the Message Box variety, is creating an infinite loop. Imagine a simple orchestration consisting of just two shapes, an Activate=True Receive shape (Direct-Bound, of course) and a Send shape that merely forwards the message to a FILE port. When this orchestration sends the message out, where does it go? As always, first to the Message Box. Whenever a message arrives in the Message Box, BizTalk searches for any subscriptions that match. And how will this message differ from the message that activated the orchestration in the first place? It won’t, so BizTalk will gladly fire off another instance of your orchestration to process it, and so on, until you run out of memory.