Suche

über alle News und Events

 

Alle News

 

Ein Arbeitsplatz ist mehr als nur ein Ort, an dem...

Weiterlesen

Am 01. Oktober ab 12:30 Uhr treffen sich...

Weiterlesen

Die Nutzung des Postman Mock Servers ist einfach...

Weiterlesen

Ein Community-Held feiert seinen Erfolg: „WOW! Ich...

Weiterlesen

Einfach großartig! Die Stimmung war hervorragend....

Weiterlesen

Rules, Rules, RULES!! Dan Toomey, The evolution of...

Weiterlesen

Keynote von Slava Koltovich, Feature: E2E - AIS...

Weiterlesen

Inspirierende Messeerfahrungen auf der 'Zukunft...

Weiterlesen

In diesem Artikel wird beschrieben, wie ihr eure...

Weiterlesen

Messaging mit dem Service Bus ermöglicht die...

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