Yet more great content over on the (RedGate sponsored) Simple Talk blog, this time an excellent article on tracking down deadlocks using SQL Profiler by Brad McGhee, well worth a read before your production system starts to exhibit this behaviour!
Archive for June, 2008
When we make changes to our BizTalk environments, we always ensure that the changes are scripted so the Ops Team don’t really need worry about messing things up – as a result, we use Binding files everywhere. Normally, we do large scale solution deployments, but earlier this week we needed to update the subscription filter on a single Send Port; to my surprise, I was pleased to discover that Binding files can be used to update existing (unenlisted) Send Ports – no need to delete and re-create (via the binding file).
Consider the scenario above, we have a Send Port subscribing to messages where the Receive Port Name = ‘Sample Receive Port’:
To update the subscription using a bindings file, strip the Bindings file down to just the Send Port in question and update the <filters> element to include a new subscription (a filter on BTS.InboundTransportType has been added in this case, the operator of zero indicates that its an equals predicate):
With the Send Port in the unenlisted state, import the updated bindings file either BizTalk Admin Console or BTSTask and the filter conditions on the Send Port will be updated:
Enlist and start the Send Port!
Note that any configuration property on a Send Port can be updated in this way.
My old colleague Mike Stephenson just e-mail me to help promote the inaugural UK SOA/BPM User Group Meeting, which will be taking place on Thursday 17th July 2008 at Microsoft’s London office.
The meeting will include a presentation on Oslo (Microsoft) and Enterprise Computing in 2015 (SunGard), plus the obligatory beer and pizza – full details can be found at the UK SOA and BPM User Group website.
If you’re in the London area, I’m sure it will be an excellent first meeting. Unfortunately, I can’t make it – I will be diving with seals off the coast of Northumberland – its a hard life!!
I know I’m going to forget how to cluster the ESSO Master Secret Server, so I’m including a link to this technical article for Microsoft Host Integration Server 2004 which gives the most succinct version of the instructions to this non-trivial task I have found so far – see ‘5.4 Clustering the Master Secret Server’ in the document for the instructions.
Thanks to Tomas Restrepo for the pointer to the document.
Victor Fehlberg’s article on Zombies has prompted me to blog about a similar problem I recently encountered with instances that have ‘completed without consuming all of their messages’ and propose yet another BizTalk Zombie Pattern.
The Technet article on Zombies in BizTalk 2006 details three types of Zombie messages:
- Terminate control messages;
- Parallel listen receives; and
- Sequential convoys with non-deterministic endpoints.
Victor’s article deals with the common pattern that falls into the third category – a while loop surrounding a listen with one branch having a receive and the other having a delay shape, followed by a construct which sets a variable to indicate that the while loop should stop. This is non-deterministic since the delay could be triggered, but a message could still be delivered.
But I believe I’ve discovered yet another non-deterministic pattern that will always produce zombies; it doesn’t quite fit the pattern described above or on Technet, but it does use sequential convoys and in my opinion, is also non-deterministic.
The branching non-deterministic zombie pattern
Consider the orchestration in the image to the left, we have a sequential convoy (albeit without the while loop, but you get the idea) which can either branch and collect the next message in the convoy (down the ELSE branch) or terminate the orchestration (down the TERMINATE branch).
If a second message is received and correlated to this particular orchestration, but the workflow logic has determined that we will go down the TERMINATE branch, the second message will never be received by the orchestration, causing a zombie. Every. Single. Time. In my opinion, this is non-deterministic in the truest of senses: at the start of the orchestration you cannot determine whether the ELSE or TERMINATE branch will be traversed!
Is there a good reason for using this sort of pattern?
I’ve been trying to think why a sequential convoy would require this kind of branching functionality and I honestly can’t think of a good reason, unless the messages being delivered to the orchestration were controlled in some way.
More to the point, I’m surprised that the XLANG/S compiler lets you even create an orchestration with the sort of potential damage that this pattern presents!
If you are using this kind of pattern, I’d be interested to know how (and why)?
And in case you’re wondering, a very similar pattern was noticed by our testing team who encountered missing messages on our UAT environment; on closer inspection of live, we had just over 10,500 suspended, zombie instances…. Ouch.
Debugging the problem took half a day and made me realise that we really do need a good tool to help search for subscriptions based on the context properties in a message, rather than the out-of-the-box Admin Console Subscription Viewer.
Sample project
If you’re interested in trying out the pattern for yourself, download the sample project and test messages.