none
Zombies in Biztalk Orchestration

    Question

  • Hi,

    According to my business process I created a
    1. Sequential Convoy orchestration which has two receives.
    2. A element was property promoted from the schema where depending on the promoted property I will be receiving messages.

    3.Correlation sets were created for this promoted property

    4.On receive 1 -Initialized Correlation set property was enabled
    5. in a listen shape where i was using  Receive 2 -Following Correlation sets and on the other side with a delay shape with 1 min delay followed by expression shape for terminating the loop.

    6.We have enabled a service window where we process messages from 4:00AM in the morning to 8:00 PM in the evening every day.

    This pattern is introducing Zombies.  How can I avoid Zombies and how much delay can I use in the delay shape?

    Thanks for your time.


    kk.12

    Wednesday, August 21, 2013 2:27 PM

Answers

  • Hi KK,

    Then you just need to increase the delay time (more approximate) and customize the Orchestartion threshold(mentioned in above reply).


    I hope this helps!!!!!! Maheshkumar S. Tiwari|BizTalk Developer Interview Questions and Answers http://tech-findings.blogspot.com/

    • Proposed as answer by Maheshkumar S TiwariMVP Wednesday, August 21, 2013 3:18 PM
    • Marked as answer by K.12 Friday, September 13, 2013 2:17 PM
    Wednesday, August 21, 2013 3:18 PM
  • So, here's the question, even though M1 and M2 have the same ID, do they have to be processed by the same Orchestration instance?  If they come in order from the queue, M2 will always be processed after M1, even though other message ID's may get processed between.

    If that's the case, don't correlate on the ID, just have one Singleton processing everything.

    Or, increase the Delay to accommodate the actual processing time.

    Thursday, August 22, 2013 6:37 PM

All replies

  • When using a sequential Convoy like this, there's no way to definitively eliminate the possibility of Zombies.

    However, I'd first offer that 1 minute it too short to wait.

    Because you have a set Service Window, here's two options to try first:

    1. Increase the wait time to something that in no reasonable circumstance should fire before all messages are consumed, 1 hour, 2 hours, it's whatever you determine.

    2. Use a specific DateTime instead of a TimeSpan for you Delay Shape.  Anything up to 0359hrs would cover the entire day's processing windows, timing out just before the next day kicks in.

    Either way, you would program your Orchestration do do nothing meaningful after the Delay, so it shouldn't matter how long the Service Instance (Orchestration) lasted in BizTalk.

    • Proposed as answer by boatseller Wednesday, August 21, 2013 3:26 PM
    Wednesday, August 21, 2013 2:41 PM
  • The zombies would get introduced if the subsequent receive do not occur within the delay period.. If you can handle this scenario properly then no zombies.

    Your delay should be able to support the scenario of the initiator message being received @7:59 PM and the because of the service window, the remaining convoy to come subsequent morning after 4:00 AM [The delay shape can be used using the TimeSpan datatype which has a constructor that can take days - as an Int32 ~ 65536 days]

    Regards.

    Wednesday, August 21, 2013 2:42 PM
  • Hi KK,

    Can you let us know how many correlated messages you want/will be there for completing .

    Say if you need more 3 correlated messages then you can have a loop until 3 .

    And before Delay shape you can check whether loop is completed , if yes then skip delay else have delay with approximate time which you think will be fair enough to wait for related messages. 


    I hope this helps!!!!!! Maheshkumar S. Tiwari|BizTalk Developer Interview Questions and Answers http://tech-findings.blogspot.com/

    Wednesday, August 21, 2013 2:44 PM
  • Thanks for your reply.

    I increased delay to 1 hr but with this it's creating orchestration instances for every message.

    i.e I submitted 500 messages where it created 300 orchestration instances which are active.

    The daily volume that we will receive every day will be in range 200-250 K

    will there be any issue if there are large no of orchestration instances running / active?


    kk.12


    • Edited by K.12 Wednesday, August 21, 2013 2:59 PM edit
    Wednesday, August 21, 2013 2:58 PM
  • Hi KK,

    That should not be a problem because Orchestration gets dehydrated after the threshold .

    You  can customize orchestration threshold. Below link will help you to do that:

    http://msdn.microsoft.com/en-us/library/ff629703.aspx


    I hope this helps!!!!!!

    Maheshkumar S. Tiwari|BizTalk Developer Interview Questions and Answers

    http://tech-findings.blogspot.com/


    Wednesday, August 21, 2013 3:08 PM
  • If increasing the delay is resulting in every message creating a new instance then I'd say your correlation set is not proving to be very effective.

    Also, between the two receives, the orchestration should dehydrate. A large number of effective subcriptions does impact the message receive process as for every received message of this type, BizTalk has to locate first if an existing subscription is met (this implies that the search on <targetnamespace>#<messagetype>#<correlation properties> within the subscription DB will result in a search across larger record sets (and thus a few second more each time).

    You may also want to check with the sending application on what is the pattern they use. Do theyw wait for a confirmation for submission of each message before firing the next one in the convoy or whether they have a parallel dispatch mode for all messages of the convoy.

    Regards.

    Wednesday, August 21, 2013 3:09 PM
  • Thanks for your reply.

     I don't have exact value of correlated messages that i receive every day.There might be one or any my requirement is to process the first request and then only go for the second for a message with same ID


    kk.12

    Wednesday, August 21, 2013 3:13 PM
  • Hi KK,

    Then you just need to increase the delay time (more approximate) and customize the Orchestartion threshold(mentioned in above reply).


    I hope this helps!!!!!! Maheshkumar S. Tiwari|BizTalk Developer Interview Questions and Answers http://tech-findings.blogspot.com/

    • Proposed as answer by Maheshkumar S TiwariMVP Wednesday, August 21, 2013 3:18 PM
    • Marked as answer by K.12 Friday, September 13, 2013 2:17 PM
    Wednesday, August 21, 2013 3:18 PM
  • I increased delay to 1 hr but with this it's creating orchestration instances for every message.

    i.e I submitted 500 messages where it created 300 orchestration instances which are active.

    If that's the case, then your Correlation scheme isn't a total Sequential Convoy.  Simply increasing the Delay would not cause extra Orchestration instances to spin up.  You must have received 300 different values for what you describe to occur.

    It's possible you just never saw them because they timed out before you got a chance to look.

    So, the question you have to settle now is exactly how 'sequential' is the message flow.  Is it true FIFO based on the source system or does a group of messages, all related by you correlation token, have to be processed in order themselves, but not in relation to the overall message flow.

    • Proposed as answer by boatseller Wednesday, August 21, 2013 3:27 PM
    Wednesday, August 21, 2013 3:26 PM
  • They don't wait for a confirmation for submission of each message before firing. They will have a parallel dispatch for all messages.

    Let us suppose If I increase the delay time to 12 hrs  and  a new message arrives at 7:59 PM  then this instance will be active for 12 hrs which will be 8:00 AM the next day .  (In the delay shape I am using TimeSpan data type).

    Please correct me if I am wrong


    kk.12




    • Edited by K.12 Thursday, August 22, 2013 2:57 PM
    Wednesday, August 21, 2013 3:28 PM
  • If the service window is closed, the calling service will get a SOAP exception because the BizTalk port that is supposed to process the message from IIS will not accept messages. Secondly the instance will DEHYDRATE (means it will create the subscription with the following correlation and go to sleep).

    Ask the calling service is for a convoy they can sequence the message calls in a loop. Different convoys can be parallel threads.

    Regards.

    Wednesday, August 21, 2013 4:02 PM
  • Is the service window implemented on the Receive Location?  Then no new messages should be submitted while the windows is closed.

    So, once the Orchestration catches up, there really shouldn't be any Zombies because there are no new messages being published/routed to that instance.  In that case, even a delay of 5 seconds will not be a problem.

    Is is possible you're Orchestration pattern is not optimized for a true Sequential Convoy?  If you expect the Orchestration to complete, the Listen/Delay shapes should be the last Shapes in the Orchestration.  That is to minimize the time the Orchestration is active beyond the last message Receive Shape.

    Wednesday, August 21, 2013 5:57 PM
  • Yes the service window is implemented on receive location.

     for implementing sequential convoy created

    1. Receive  Shape -Initialize correlation sets.

    2. Loop Convoy = true

    2. Process the message

    3.Send to the client

    4. Listen for next message- Listen shape with Receive on side (Following Correlation sets)and delay shape and terminate loop on the other side

    Listen and delay shapes are the last shapes in my design.


    kk.12


    • Edited by K.12 Wednesday, August 21, 2013 6:12 PM
    Wednesday, August 21, 2013 6:11 PM
  • Ok, that looks correct Pattern wise.

    Now, you mentioned you're getting many instances of the Orchestration so that presumes that the messages are 'grouped' by the correlation id.

    That's fine, but it introduces a bit of complexity/uncertainty in the convoy logic.

    In this situation, you have to allow time not only for the message to be published, but also consumed across all possible instances.

    So what can happen, and I've seen it, is that some of the Orchestrations will stay Dehydrated (while others are Active) longer than the Delay Shape's timeout.  So, when they finally get a chance to run, the Delay timer has already fired, the instance completes and any messages queued for the Receive Shape are now Zombied.

    Again, this brings the question of what exactly is the ordered requirement.

    Wednesday, August 21, 2013 6:30 PM
  • So, here's the question, even though M1 and M2 have the same ID, do they have to be processed by the same Orchestration instance?  If they come in order from the queue, M2 will always be processed after M1, even though other message ID's may get processed between.

    If that's the case, don't correlate on the ID, just have one Singleton processing everything.

    Or, increase the Delay to accommodate the actual processing time.

    Thursday, August 22, 2013 6:37 PM