locked
Understnding zombies RRS feed

  • General discussion

  • I have singelton pattern implemented at my end . I just try to run big file than usual around 18500 messages in in coming file. I found around 400 messages goes as zombies message. In my case Lister shape I kept 15 minutes . 

    I know sequential convoy create zombies messages. But is it normal that ir create this much zombie messages or there is something wrong in implementation ? What could be better way to reduce number of zombies (I know we can not remove it but learn to minimize ).

    Thursday, October 2, 2014 3:36 PM

All replies

  • How you do you know they are zombies. 400/18500 makes me to think, the implementation could also be a problem.

    Refer these excellent article from one of our community members - Leonid. These articles can help you understand zombies and its creation better.

    http://geekswithblogs.net/LeonidGaneline/archive/2011/02/05/biztalk-instance-subscription-details.aspx

    http://geekswithblogs.net/LeonidGaneline/archive/2011/02/09/biztalk-suspended-shape-and-convoy.aspx


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, October 2, 2014 4:11 PM
  • this is error message 

    The instance completed without consuming all of messages.The instance and its unconsumed message have been suspended

    Thursday, October 2, 2014 4:22 PM
  • If you actually have multiple Singletons running, meaning the 18,500 messages is really several different groups each processed by it's own Singleton, then what you are seeing is not surprising.

    What's likely happening is something like:

    1. Singleton 1-7 get activated.
    2. Singleton 3-7 process their 18,000 messages while some message routed to Singleton 1 and 2 are at the end of the queue.
    3. 15 minutes elapse while Singletons 3-7 are processing their message so the Delay in Singletons 1 & 2 fire and the Orchestration ends.
    4. Messages still pending for Singleton 1 & 2 are now Zombies.


    Thursday, October 2, 2014 4:22 PM
    Moderator
  • I think what ever you are explaining make sense. What is solution , just increase delay time? or there could be better solution?


    Thursday, October 2, 2014 4:51 PM
  • Using a longer Delay timer is a quick fix.

    There really isn't a single 'solution' to the Zombie problem, just designing your application to mitigate them.

    Thursday, October 2, 2014 6:06 PM
    Moderator
  • Someone once told me this really good quote: "You cannot beat time, so there is no 'real' bullet proof way to avoid zombies..."

    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    Thursday, October 2, 2014 6:33 PM
  • Hi,

    Some the things you can do is:

    1>After your orchestration exists the collect loop remove all the logic (may be use another orchestration via an asynchronous call -start orch shape).That way the possibility of an message bumping into a zombie scenario reduces.

    2>If you are in a need of quick fix try using the Error message routing pattern used here:

    http://psrathoud.wordpress.com/2014/06/30/error-message-routing-pattern-demo-in-biztalk/

    However a good long term approach will be to create a custom pipeline which will subscribe to Zombies

    Regards

    Pushpendra

    Thursday, October 2, 2014 8:17 PM
  • You could set a delay for hours, if it makes sense in your case. I totally agree with boatseller, that good design helps here. Think through all aspects of your situation, make sure you understand what is going on.

    Before doing this, make sure you will not get problem with memory, when messages are set in some service instance and do not removed after processing. So measure the memory consumption in your case.

    Do not forget, the host instance is an instance of queue. Sometimes adding more hosts (hence queues) and separate different subscribers to different hosts (queues) could help to mitigate a problem of a too-long queue.


    Leonid Ganeline [BizTalk MVP] <a href="http://social.technet.microsoft.com/wiki/contents/articles/20258.biztalk-integration-development-architecture.aspx">BizTalk Development Architecture</a>


    Friday, October 3, 2014 4:30 AM
    Moderator
  • One behavior I saw in production.Not sure is it random or something serious . I will keep watch for few weeks.

    I got zombie messages for very small file that is 25 messages only. It left last 2 messages to process.

    I have incoming EDI file and I have singleton where I am processing upto last message (considering 997 is last message).I kept 15 minutes in lister shape , I think it is good enough for 25 messages. I can understand if I get zombies for big file. 

        I can write process to handle zombie. But I like to understand why I am getting it for small data and if any way we can avoid it for small files at least.

        

    Wednesday, October 15, 2014 4:49 PM
  • Recently I saw a workaround on the similar EDI problem. The pipeline component, that works after disassembling component, searches for a footer message (the 997) and delays on it. So, the 997 is published to the MessageBox after all body messages. It eliminates the zombie problem which is created if 997 is published before some body messages.

    Leonid Ganeline [BizTalk MVP]

    Wednesday, October 15, 2014 5:40 PM
    Moderator
  • I did not get what is workaround? You mean add one pipeline component after disassembling which will look for 997 message and keep it hold sometime (till other messages finished).

    In short include custom pipeline component to looks and hold 997? In this case how I will know all messages processed or not ? 

    Wednesday, October 15, 2014 5:57 PM
  • Yes, it is a custom pipeline component to looks and hold 997 (creates a delay for 997).

    This workaround does not eliminate the problem, it does not know all messages are processed. It is just assumed "all messages are processed in xx minutes". Is is a workaround.


    Leonid Ganeline [BizTalk MVP]

    Wednesday, October 15, 2014 6:04 PM
    Moderator
  • Thanks let me try that
    Wednesday, October 15, 2014 7:08 PM