When diagnosing and resolving failed BizTalk messaging, sometimes I forget to play by the same rules as the originating processing model.
Namely, selecting all the suspended message in the queue and just resuming them again may cause all kinds of concurrency (SQL locking) problems on top of the original issue.
This touches on a much deeper topic of knowing what you’re getting into before messing with stuff, but that’s a conversation for another day.
Moral of the story here: when diagnosing problems, work on one thing at a time. Resume one message, wait for the results, then confirm that the 'solution' actually solved the problem.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment