Справочная информация:
Мы используем множество агрегатов, одноэлементных и многотонных оркестровок, подобных Методика Round Robin Серотера, описанная здесь (BizTalk 2009).
Все эти типы оркестровки имеют довольно произвольные точки выхода или продолжения (для агрегатов), обычно определяемые таймером - то есть, если Orch не получил больше сообщений в течение X минут, продолжите пакетирование, и если через Y минут больше истекли, и сообщений больше нет, затем выйдите. (Мы также закрываем наши одиночные / N-тонны из-за опасений по поводу снижение производительности после того, как большое количество сообщений подписано на синглтон в течение определенного периода).
Насколько мы пытались смягчить последствия против зомби, например При запуске любой обработки продолжения в оркестровке с асинхронным рефакторингом всегда есть слабое место, где «своевременное» сообщение может вызвать зомби. (т.е. получение большего количества входящих сообщений, связанных с «уже завершенными» формами оркестровки),
Если сообщение вызывает зомби на одной из подписок, сообщение, похоже, не распространяется и ДРУГИМ подписчикам (то есть орки полностью отделены от оркестровки, вызывающей зомби), то есть сообщение, вызывающее зомби, не обрабатывается.
Вопрос
Поэтому мне было бы очень интересно узнать, есть ли у кого-нибудь другой способ, программно или иным образом, явно удалить коррелированную подписку из работающей оркестровки, как только оркестровка «продвинется» дальше той точки, где она заинтересована в этом коррелированном сообщении. (это новое сообщение обычно запускает новую оркестровку со своими собственными корреляциями и т. д.)
На этом этапе мы могли бы рассмотреть даже решение для взлома, такое как отраженный вызов API BizTalk или прямое удаление SQL для MsgBoxDB.
