I have a somewhat unusual problem – I have two singleton orchestrations, let’s call them Singleton-A and Singleton-B.
Singleton-A assembles a message of type Message-A and sends it to the message box via a direct bound orchestration port. Because it’s a singleton it must be running on only one host instance. So each Message-A gets sent to the messagebox in the correct order 1,2,3,4… etc. I can confirm this is true by using HAT.
Singleton-B has a subscription to Message-A. Singleton-B has a logical receive port through which it receives the messages from Singleton-A. This receive port has ordered delivery set to true. Singleton-B of course is also single threaded. But when the messages sent by Singleton-A are consumed by Singleton-B they are consumed in the wrong order 1,2,4,3… etc. Again looking in HAT I can see this is true.
The order in which Singleton-B processes the messages seems completely non-deterministic. What is happening here? Is the subscription evaluation and/or host-queue en-queueing process multithreaded? Is it fair to assume that BizTalk will not support ordered delivery between singleton orchestrations?
This is still an outstanding issue – I believe it is a bug in BizTalk. However we have rearchitected our solutions to never have singleton orchestrations direct bound to the output of other singleton orchestrations.
Incidentally this is bad design in the first place as BizTalk is primarily designed for high volume, parallel message processing.