5

背景：

我们使用了很多聚合、单例和多例编排，类似于此处描述的 Seroter 的循环技术 (BizTalk 2009)。

所有这些编排类型都有相当任意的退出点或延续点（用于聚合），通常由计时器定义 - 即如果 Orch 在 X 分钟内没有收到更多消息，则继续批处理，如果在 Y 分钟后继续已经过去，没有更多的消息然后退出。（我们也退出了 Single / N-Tons，因为担心在一段时间内大量消息订阅单例后性能会下降）。

尽管我们试图减轻僵尸的影响，例如通过在异步重构编排中启动任何继续处理，但始终存在一个弱点，即“适时”的消息可能会导致僵尸。（即接收更多与编排的“已完成”形状相关的传入消息），

如果一条消息导致其中​​一个订阅出现僵尸，则该消息似乎也不会传播给其他订阅者（即，orch 与“僵尸导致”编排完全分离），即不处理导致僵尸的消息。

问题

因此，我很想看看是否有人有另一种方式（以编程方式或其他方式），一旦编排“进展”到超出对相关消息感兴趣的程度，就可以从正在运行的编排中显式删除相关订阅。（然后，这个新消息通常会开始一个具有自己相关性等的新编排）

在这一点上，我们甚至会考虑一个 hack 解决方案，例如反射 BizTalk API 调用或针对 MsgBoxDB 的直接 SQL 删除。

4

1 回答 1

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.

于 2013-08-21T04:50:03.733 回答