Problem
In der HV-Installation suspenden sich sporadisch Nachrichten und können nur manuell wieder resumed werden. Nicht gerade sehr erfreulich - v.a. bei hoher Last ;-( Die Ursache: Deadlocks. Eine typische Fehlermeldung im Eventlog lautete:
A message sent to adapter "HTTP" on send port "kunde.AS2.ORDERS-DESADV" with URI "http://80.149.96.170:4080" is suspended.
Error details: There was a failure executing the send pipeline:
edihub.kunde.pipelines.as2.AS2EdiSendRemoveTestIndicator, edihub.kunde.pipelines.as2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b0b82818d5063765" Source: "AS2 encoder" Send Port: "kunde.AS2.ORDERS-DESADV" URI: "http://80.149.96.170:4080" Reason: Unable to create the entry in the AS2 EDIINT MIC table. This could be caused by duplicate AS2-From, AS2-To and MessageID combinations being written to the table. Error: Transaction (Process ID 242) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
MessageId: {51079E0C-5031-438A-82AD-75CAB624D3A2}
InstanceID: {CDB378BA-8360-41EB-AA2A-5E90FA9BC4C7}
Da der Fehler nur sporadisch auftrat, konnte er nicht in der Anwendung liegen. Wir mussten tiefer graben und wurden schließlich in den DB-Einstellungen des BizTalk Servers für Parallelität fündig. Bei fehlerhafter Konfiguration werden bestimmte Nachrichtenvorgänge so parallel abgearbeitet, dass sie Ressourcen gegenseitig blockieren. Es kommt zu Deadlocks, welche die Nachrichtenverarbeitung auf einen Fehler laufen lassen.
Lösung
Die Konfiguration für den Wert 'Max Degree of Parallelism' war nicht korrekt gesetzt.
Auf der Maschine, auf welcher der SQL Server mit der BizTalkMsgBoxDb läuft, müssen der Max Degree of Parallelism-run_value und -config_value beide auf den Wert '1' gesetzt sein. Andernfalls kann es tatsächlich bei höherer Last zu Deadlocks aufgrund falscher, paralleler Verarbeitung kommen.
Um herauszufinden, welchen Wert die Max Degree of Parallelism settings haben, kann man die folgende stored procedure auf der Master db im SQL Server ausführen:
exec sp_configure 'max degree of parallelism'
Wenn der run_value and config_value nicht beide den Wert '1' haben, kann man die folgende stored procedure im SQL Server ausführen, um diese auf '1' zu setzen:
exec sp_configure 'max degree of parallelism', '1'
reconfigure with override
Dann muss der SQL server neu gestartet werden. Und die Deadlocks sind erfolgreich ausgesperrt.
