5

Background:

We make use of a lot of aggregation, singleton and multiton orchestrations, similar to Seroter's Round Robin technique described here (BizTalk 2009).

All of the these orchestration types have fairly arbitrary exit or continuation points (for aggregations), usually defined by a timer - i.e. if an Orch hasn't received any more messages within X minutes then proceed with the batching, and if after Y more minutes have elapsed and no more messages then quit. (We also exit our Single / N-Tons due to concerns about degraded performance after large numbers of messages are subscribed to the singleton over a period).

As much as we've tried to mitigate against Zombies e.g. by Starting any continuation processing in an asynch refactored orchestration, there is always a point of weakness where a 'well' timed message could cause a zombie. (i.e. receiving more incoming messages correlated to the 'already completed' shapes of an orchestration),

If a message causes a zombie on one of the subscriptions, the message does not appear to be propogated to OTHER subscribers either (i.e. orchs totally decoupled from the 'zombie causing' orchestration), i.e. the zombie-causing message is not processed.

Question

So I would be very interested in seeing if anyone has another way, programmatically or otherwise, to explicitly remove a correlated subscription from a running orchestration once the orchestration has 'progressed' beyond the point where it is interested in this correlated message. (this new message would then would typically start a new orchestration with its own correlations etc)

At this point we would consider even a hack solution such as a reflected BizTalk API call or direct SQL delete against the MsgBoxDB.

StuartLC
  • 104,537
  • 17
  • 209
  • 285
  • Since that perf. problem was with 2006, do you need to shut down the orchestrations? I've used that pattern with large quantities of messages with success in bt2009. The orchestration ran continuously. To safely shut them down I stopped the source, then the orchestrations. – Derek Beattie Sep 20 '11 at 13:31
  • Unfortunately, most of our incoming traffic comes from a Single MQ queue, so stopping the receive port would affect all our apps. But you are right - it is a case of 'concerns' about leaks than bona fide evidence (e.g. seeing 50k+ messages attached to the singleton is daunting). Under exceptional load, suspending a few of the singleton orchs works fine and then resuming once server has recovered / completed with more urgent work (since by 'design' only non latency-critical messages would be assigned to Singletons / Round-Robins). – StuartLC Sep 21 '11 at 10:58
  • Is is possible to add another queue in between the existing queue and the current receiver? That way you can stop the new receiver and gracefully shutdown orchestrations. – Derek Beattie Sep 21 '11 at 13:09
  • OK, point taken that if we turn ALL orchestrations which have any kind of correlation into Singletons / N-Tons which never exit (ever), we will avoid Zombies. But for scalability purposes I wouldn't want to turn our aggregator orchs into singletons. But it just seems to me that being able to remove a subscription at an appropriate time would avoid these kinds of workarounds. – StuartLC Sep 21 '11 at 13:53
  • I probably don't fully understand your setup. Even with one Queue, you can have multiple orchestrations running processing by correlation. I did this by grouping the inbound messages based on some criteria, in my case, stores. So one orchestration could handle 10 stores, it worked well. – Derek Beattie Sep 21 '11 at 17:27
  • Fwiw we have managed to cut our zombies down to nearly zero, simply by profiling incoming correlated messages and understanding statistically the profile of frequency of an incoming correlated messages. 'Hand-off' orchestrations (correlate, promote context properties for downstream subscribers, and then exit quickly) also mitigate nicely. But am still uneasy that a zombie could occur. – StuartLC Feb 24 '12 at 19:20

1 Answers1

1

No you can't explicitly remove the subscription in an Orchestration.

The subscription will be removed as the Orchestration is tearing itself down, but a message arriving at that exact instance will be routed to the Orchestration but the Orchestration will end without processing it, and that's your Zombie.

Microsoft Article about Zombies http://msdn.microsoft.com/en-us/library/bb203853.aspx

I once also had to have an receive, debatch, aggregate, send pattern. Receiving enveloped messages from multiple senders, debatching them, aggregating by intended recipient (based on two rules, number of messages or time delay, whichever occurred first). This scenario was ripe for Zombies and when I read about them I designed it so it would not occur. This was for BizTalk 2004 I debatched the messages, and inserted them into a database. I had a stored procedure that was polled by a receive port that would work out if there was a batch to send in if there was it would trigger of an Orcherstration that would take that message and route it dynamically. Since neither Orchestrations had to wait for a another message they could end gracefully and there would be no Zombies.

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54