Zombies in BizTalk

Question

Hi guys,

I have a BizTalk 2006 R2 application that works perfectly. It receives the messages, processes them and sends correct responses.

But although the everything is correct (the messages are successfully picked up by the orchestrations and the response is sent without errors), BizTalk still generates a "Message not consumed" error related to the response message...

I've debugged every bit of the application and there is no error, no duplicated message, no message left behind, nothing... I googled the error and the vast majority of the few links that I find on the subject are related to zombie clean up scripts. This makes me wonder if this is not a common issue in BizTalk...

Does anybody have any idea on what may be causing this error?

Answer 1

Where do you see the error? in the event log? Can you post it here?

Answer 2

This sounds like a zombie. Does your orchestration use correlation and a wait time? If so, you're in Zombie Land. The issue is that you have a wait and a seocndary read waiting to see which triggers first. If the wait triggers first and then a new message on the correlation comes in... Zombie.

Let us know more about your orchestration and we can further discuss a solution.

Answer 3

Yeah ... this is a common issue which can most of the time be overcome by a slight change in the way your solution is put together.

Zombies usually occur when using correlations and time-outs, but not the only time. The orchestration is dehydrated waiting for either a response to the correlation set or the time-out, if the time-out occurs the orchestration proceeds to process usuall past the receive location waiting for the correlated response. Now the message box gets the response but there is no longer anything waiting for that response. Hence your error.

I've also seen this behavior when calling a web service and waiting for a response; but this had to do with how I was handling errors. A small change to my process resolved that problem.

Ways to minimise the occurance of this problem is to shorten the amount of work the orchestration does after the time-out. Make the window for Zombies to occur as small as possible.

Sometimes it is not possible to avoid this non-deterministic termination issue so I've found myself building a "ZombieHandler" process which receives these messages and cleans up after itself.

If you could post more information about your process we could try assist some more.

Answer 4

The error is in the BizTalk group panel and not in the event log and is "The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended.". Basically, I have a main orchestration that receives a message through a two way port, sends it to the message box while initializing a correlation. The next shape in this orchestration waits for a message (without any timeout logic) and follows the correlation created in the previous send shape. When a response is received it is forwarded back to the original requester.

It is a very simple orchestration (screenshot: http://img139.imageshack.us/img139/2307/orchestration.jpg) with almost no logic. The point is that i'm getting correct responses always, so I cannot figure out what is triggering the "message not consumed" error. By the way, the message flagged as not consumed is the response message.

Any further ideas?

Ps. ryancrawcour, can you elaborate on your ZombieHandler? To which properties do you bind such orchestration?

Answer 5

Why are you using a correlation set? You have an initializing receive for the correlation set, where is the following receive?

Can you take a step back and explain what is the requirement for correlation? What messages are you trying to tie togeather here? I am guessing if you remove correlation from this orchestration, it will work perfectly.

Here's a link to correlation Tutorial if you want to take a look.

Answer 6

@ChrisLoris:

Screenshot of the orchestration: http://img139.imageshack.us/img139/2307/orchestration.jpg

In the screenshot above you can see that I have an orchestration linked to a send/receive port. Basically i'm getting a message to process, update a few attributes on it and send it to the message box while initializing a correlation based on a specific property (lets call it MsgIdentifier). Other orchestrations will pickup this message and do the real processing. When a response is dropped into the message box with the same MsgIdentifier (custom property) this orchestration picks it up and sends it back to the original requester.

The correlation is initialized in the send shape that sends the request to the message box and the following receive shape waits for a response that follows the same correlation, i.e. that has the same value in the MsgIdentifier property.

Think of this orchestration as a broker, an intermediary between the external system and the inner workings of the BizTalk application.

Again, all is working properly and the correct messages are being picked up without any problems and that is the exact strange behavior that I'm trying to analyse. It shouldn't mark the response as a message not being consumed, because its being detected, consumed and returned.

Answer 7

Are there any chances that the original message is being processed by multiple orchestrations? In this case, there may be two messages put back into the message box for a response to the orchestration we are discussing. In this case, the first message would be picked up by the corrleation set. because there is no looping construct on the following receive, the second message would have no where to go - Zombie.

Answer 8

@ChrisLoris: Thank you for your patience and persistence.

No. I debugged all orchestrations and they only generate a single response. That is indeed weird. This should not happen and I cannot seem to sort out this issue.

BTW, is it possible to have an orchestration that subscribes to Zombie messages for clean up? If so, does anybody know what are the message properties to bind to?