Suche

über alle News und Events

 

Alle News

 

Wir haben während unseres...

Weiterlesen

Azure Functions benötigen oft einen...

Weiterlesen

In der heutigen Zeit nehmen Erreichbarkeit,...

Weiterlesen

Viele unserer Kunden überlegen derzeit, was sie in...

Weiterlesen

Lösungsansatz – was benötigt man dafür:

  • Einen...
Weiterlesen

Es gibt im Preview die Möglichkeit Azure Blob...

Weiterlesen

Die wichtigste Konferenz zu Integration auf der...

Weiterlesen

In diesem Blogeintrag werden wir drei sichere und...

Weiterlesen

Im vergangenen Jahr war bei uns in Hamburg viel in...

Weiterlesen

Heutzutage werden Token für die Authentifizierung...

Weiterlesen

How-to: BizTalk Message Freigabe in langlaufenden Orchestrations

Vor einiger Zeit sind wir in einem Projekt auf eine seltsame Situation gestossen: Eine langlaufende Orchestration, die viele Tausende Messages in einer Loop erzeugte und versendete, verlangsamte den BizTalk nach und nach, bis dieser irgendwann ganz aussetzte.

Bei der Analyse kam zum Vorschein, dass sich alte, nicht mehr gebrauchte Messages aus dieser Orchestration in der BizTalkMsgBoxDb ansammelten. Die BizTalk Engine erkannte offenbar nicht, dass die Messages nicht mehr benötigt wurden und gab diese nicht frei. Die immer grössere Message-Menge in der Message Box führte zur Verlangsamung, der Transaction Log wuchs stetig und sprengte irgendwann die Speicherplatzgrenzen.

Dieses Verhalten lässt sich durch folgende einfache Orchestration reproduzieren.

 

 

Der Ablauf:

1. Trigger wird empfangen.

2. Loop Count wird entnommen.

3. Loop

  1. Eine Message wird erzeugt.
  2. Eine Hilfs-Orchestration wird aufgerufen. Die Message wird by ref übergeben.
  3. Die Message wird versendet.
  4. Nächster Durchlauf wird vorbereitet.

 

Der entscheidende Punkt ist 3b.
 






Die aufgerufene CalledHelper Orchestration ist im Beispielfall absolut leer („Just Empty“) und tut nichts.
 

Durch die Übergabe des Message Orchestration Parameters by ref (Message geht rein, darf im CalledHelper neu zugeordnet werden und geht wieder raus) erkennen der BizTalk Compiler und die BizTalk Engine nicht, dass die Message nach dem Versenden nicht mehr benötigt wird. Sie bleibt bis zum Lebensende der langlaufenden Orchestration in der Messagebox.
 

Im Fortschritt kann das durch Abfrage der Spool Tabelle in der BizTalkMsgBoxDb beobachtet werden.




Im Bild zu sehen ist die Situation nach einigen Minuten Laufzeit. Die allererste Message ist die Trigger-Message, die weiteren aus den Loops. Auch aus den allerersten Loops sind die Messages immer noch da, hier sind es insgesamt schon 2233 Stück. Die Messages gehen nicht weg, solange die Orchestration läuft!

Wie kann dieses unerwünschte Verhalten verbessert werden? Eine gute Möglichkeit ist das Ersetzen der Übergabe by ref durch in.

 



Da die Message nur hereingegeben wird, erkennt der Compiler, wann sie nicht mehr benötigt wird. Die Messages werden nach dem Versenden aus der Messagebox entfernt. Ein positiver Nebeneffekt ist die höhere Performance, da Persistenzpunkte gespart werden. Wenn die Rückgabe einer geänderten (also neuen) Message notwendig ist, kann ein zusätzlicher out Parameter für die neue Message verwendet werden.

 

Als zweite Möglichkeit, für den Fall, dass der ref Parameter bleiben soll, geht Folgendes.

 

Das komplette Innere des Loops wird in einen Scope geschoben. Alle Messages, die nur im Loop benötigt werden, werden nicht ausserhalb, sondern im Loop Scope deklariert. Der Loop Scope muss zusätzlich den Transaction Type Long Running haben (die Orchestration selbst auch). Damit wird die Freigabe der unnötigen Messages erreicht, allerdings auf Kosten der Performance wegen zusätzlicher Persistenzpunkte.

 

Viel Spass beim Coding!

 

Plamen Petrow, Solution Architect

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz