Chris Restall

I may be operating under a misconception but are instance subscriptions durable Lets say I have an orchestartion, or many for that matter, that initialize a correlation set (instance subscription) and publish a message. The orchestration will dehydrate until a published message matches the followed correlation set (instance subscription).

I was under the impression that if a reboot happened while an orchestration was in a dehydrated state, the subscriptions would persist. That is upon restart, I'd still have orchestrations in the suspended state waiting. I did a simple test with correlation. While an orchestration was in a dehydrated state, I restrated the BT service, simulating a reboot. My orchestrations disappered, not to suspend, they just vanish, subsequent messages that should match on the correlation set were suspended due to routing errors.

How would this scenario be handled in a "real world" application, where you could have 100's if not 1000's of dehydrated orchestrations waiting xxx ampount of time to complete Is there a best practice or some trick to persisting dehydrated orchestrations during reboot events What about cleanup ina scenario like this, How would one rectify their orchestrations that have vanished



Re: BizTalk R2 General Instance subscriptions and durability

Leonid Ganeline - MVP

Hey mitre,
Seems you've found another bug .
Please, give us more information.
Usualy subscriptions persist.
Regards,
Leonid Ganeline





Re: BizTalk R2 General Instance subscriptions and durability

mitre

Hi Leonid

In that same correlation example described on the other issue, this time without any modification. Publish (drop into file location) the sample PO and check the Biztalk administration tool. You should see the orchestration has dehydrated in HAT. Now go into services and restart the Biztalk service, then refresh the admin tool. On my R2 installation, the orchestration instance is gone and nothing is suspended..

Please let me know if this is occurring for you as well. After reading:

http://blogs.msdn.com/biztalk_core_engine/archive/2004/08/03/206589.aspx

"Unenlisting a service causes the subscription to ˇ°go awayˇ±. "

I am now thinking that this is expected behavior





Re: BizTalk R2 General Instance subscriptions and durability

mitre

Update on this.

I cannot seem to reproduce the non-persistence issue. I went back and tried this series of steps again and it seems to dehydrate as it should and survive restarts. The only thing I can think of is I was iusing the orchestration debugger in HAT which has resulted in some reproduceable oddities as far as suspends and dehydrations go.

I'm relieved in a way that the persistence peice works as I originally thought, just wish I could duplicate what I was seeing earlier.





Re: BizTalk R2 General Instance subscriptions and durability

Leonid Ganeline - MVP

mitre wrote:

...

"Unenlisting a service causes the subscription to ˇ°go awayˇ±. "

I am now thinking that this is expected behavior

Yes, it is an expected behaviour.
Enlist = Subscribe
Unenlist = Unsubscribe
I'm feeling some differences in terms, but, IMHO, this difference is too small to start new terms (I mean terms "Enlist/Unenlist")