Orchestration Subscription Throttling

  • Article

One of the less heard features of orchestration throttling is Subscription Throttling.  The Subscription based throttling will decide when to pause/resume the messages from moving to Subscribing orchestration instance based on the number waiting to be consumed.

new-bitmap-image

Recently I came across a scenario, where we had to utilize this functionality, but we don’t have a performance counter to check if we hit this condition or not. Like we use to figure out high memory or high database size or other throttling condition via perfmon counters.

After collecting Microsoft internal Biztalk Traces(PSSDIAGforBiztalk), we found

Line 6001: [1]0E10.1BDC::09/06/2016-10:34:05.244 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 392a204f-c859-4323-a9e4-fa090d6832e9 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb

Line 6039: [1]0E10.1BDC::09/06/2016-10:34:05.247 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 574e34be-9ada-41b9-bb01-4151ee8d2996 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb

Line 6078: [1]0E10.1BDC::09/06/2016-10:34:05.247 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 08822c2a-e179-4c79-8442-e03645c73fc7 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb

Line 6116: [1]0E10.1BDC::09/06/2016-10:34:05.247 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 96f85380-813f-4512-a04e-12bdbcf9f55c sub=280989aa-3eed-476f-b32f-f1c57b1ddceb

Line 6154: [1]0E10.1BDC::09/06/2016-10:34:05.248 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 101c52c5-8b59-46c6-9b51-63f3d13fe3e9 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb

Line 6192: [1]0E10.1BDC::09/06/2016-10:34:05.248 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 2b77b798-a3c2-4c7e-92c1-fd3b65a86d19 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb

Line 6193: [1]0E10.1BDC::09/06/2016-10:34:05.248 [CSharp]:XLANG:Subscription.Deliver: suspending subscription 280989aa-3eed-476f-b32f-f1c57b1ddceb, instance 1553b96b-bdbb-492d-8f48-649d06ad414f

 

Currently, I have set the value Pause/resume at 5:3. So when the sixth message arrived, the subscription was suspended and avoided messages to be sent to the actual orchestration instance. But you will still find the messages being refereeing in the orchestration instances( as you can not make it a suspended or subscription failure, on the subscription is paused)

new-bitmap-image-2

to check the subscription has throttled or not, you can check the Subscriptiontable(for Normal orchestration) or ConvoySetinstancetable(for Convoy Orchestration), first you will find fEnabled set to true and then the fpuased flag will be set to true, which will control the orchestration Subscription throttling.

In my example I had Subscription pause at set to 5 and resume at set to 3, and could see the pause at value being modified when the message crossed 5, the paused value was 1 and when it reduced to 3, the pause at value changed to 0.

new-bitmap-image-3

After Resume value reached when the orchestration contains less than 3 messages

new-bitmap-image-4

This is not visible in admin console, as all the messages are in the same state because only the subscription is suspended or resumed.

Hope this helps!!

Happy BizTalking