Großer Inhalt für eXTra-Nachricht

[Dr. Lofi Dewanto]

Hallo Zusammen,

ich habe eine Frage bzgl. der Große einer eXTra-Nachricht: Wie gehe
ich mit "sehr großer eXTra-Nachricht" um? Bspw. 10 GB? Wie ich von
Florian verstanden habe, gibt es derzeit bis zu 20 MB eXTra-Nachricht.
Was ist wenn die Nachricht sehr groß wird? Muss / kann man sie in
mehreren eXTra-Nachrichten zerstückeln? Wie funktioniert das?

Viele Grüße
Lofi Dewanto.

[Florian Stratil]

Ich glaube, ich sollte mein Büro mal nach Wanzen absuchen... Ich habe mich heute erst mit einem Entwickler im Zusammenhang mit dem Server über genau das Thema unterhalten und da gibt es ein paar interessante Facetten.

Erstmal zur eigentlichen Frage:

20 MB an sich sind schon eine Menge Holz. Das waren 10 000 MVDS-Nachrichten im ELENA-Bereich bzw. die EuBP hat das als Limit ausgegeben um damit 3 Jahre Daten für die Betriebsprüfung zu bekommen. WIe ich dann heute gesehen habe liegt der Durchschnitt der Meldungen die wir über Sofortmeldungen in diesem Monat bekommen haben bei 7,5 kb. "Große" Sendungen schlagen da mit 200-250kb zu Buche.

Die Frage die man sich dann bei sehr großen Sendungen stellen muss, ist ob die Sendung an sich so atomar ist, dass ich gezwungen bin wirklich die x MB am Stück zu senden oder ob ich im Prinzip die Möglichkeit habe, das ganze in eine Anzahl n Einzelsendungen zu unterteilen.

Sollte das erste der Fall sein, dann muss ich mir wohl auf fachlicher Ebene eine Systematik einfallen lassen, die es mir ermöglicht aus vielen Sendungen wieder eine Einzelsendung zu machen. Ähnlich dem Prinzip des Dateisplitters aus der Disketten-Zeit. Ich muss aus dem großen Happen viele kleine verdaubare Happen machen (Warum man das tun sollte, werde ich dann gleich noch sagen...).

Wenn ich es doch teilen kann, spricht nichts dagegen die Sendung auf die Paketebene zu verteilen oder eben mehrere Requests zu machen, bei denen ich ein Limit (z.B. Zahl der Datensätze) festlege um die Sendung nicht zu groß werden zu lassen.

...denn, dass der eXTra-Request das kann ist die eine Sache.

Die andere ist dann die Technik.

Irgendwo steht nämlich dann ein armer eXTra-Server auf einem Application-Server, der das ganze entgegennehmen muss.

Der Request schlägt beim Application-Server ein. Bis die vielen MB dann erstmal beim Server sind, wird es auf der Client-Seite vielleicht schon kritisch was den Timeout der Leitung angeht. Wenn das gutgeht, dann heißt das aber noch lange nicht, dass die Daten sicher übertragen werden. Im Normalfall findet ja eine Schema-Prüfung statt und es ist ein erstes parsen des Requests angesagt. Auch hier geht wieder Zeit drauf, die sich negativ auf den Timeout auswirken.

Die Kollegen, die den Server implementieren, haben mich dazu sorgenvoll angerufen und erstmal gefragt wie wahrscheinlich die maximale Belastbarkeit von 100 MB eigentlich ist.

Der Grund:

Beim Testen hat sich herausgestellt, dass ein Request von 100 MB, die Java-Heapsize auf dem Server mit Leichtigkeit über die Grenze von 1,5 GB gebracht hat. Keine parallelen Requests sondern eben wirklich nur einer mit 100 MB. Ich glaube, Serverwünsche der Art muss man seinen Admins sehr vorsichtig beibringen ;)

Aus meiner Sicht sollte man also schon gute Gründe haben, warum man einen Brocken von mehreren MB auf einmal über die Leitung schickt. Und wenn man das dann tut, ist die Annahme auf dem Server eine echte Herausforderung, weil man jedes Objekt zweimal anschaut ob man es wirklich braucht.

[Oliver Staudt]

Hallo,

also nach meinem eXTra Wissen ist keine binäre Übertragung in eXTra vorgesehen. 

Daher müssen alle Daten in Base64 konvertiert werden. Dies erzeugt etwa 30% mehr Volumen.

Alleine aus diesem Grund ist es nicht anzuraten 10 GB zu versenden. 

Weitere Probleme bestehen in der Verarbeitung eines solchen Dokuments, da ein Laden in den DOM-Baum bei 10 GB eher im tot des Systems endet. So könnte man das Dokument vielleicht noch mit einem Event-Basierten Parser behandeln (SAX).

Die 100 Megabyte Nachricht, die sich auf 1,5 GB aufbläht, ist hierfür ein gutes Zeichen. Es könnte aber sein, dass es in anderen Plattformen effizienter geht. So könnte eine .net Umgebung vielleicht weniger Arbeitsspeicher brauchen. Dafür müsste man aber einen Benchmark machen, um es mit Zahlen zu untermauern. 

Weiterhin ist ein Problem, dass die 10 GB zum Base64 decoden mindestens zweimal im Speicher liegen werden. Außer man geht hier sehr geschickt vor und beschreitet andere Wege, wie der erwähnte SAX-Parser. 

Ohne jetzt auf Verbindungsprobleme während der Übertragung zu diskutieren, würde ich von so großen Daten abraten.

Ein entsprechendes Fachverfahren, das es trotzdem ausführen will, könnten aus seiner eigenen Logik heraus auch die Nutzdatei in mehrere Nachrichten aufspalten.

Mit Grüßen aus Aschaffenburg

Oliver Staudt

[Dr. Lofi Dewanto]

Hallo Herr Staudt,

danke für die Hinweise. Wir haben einige Punkte für die Spezifikation zusammengetragen, die wir gerne in der Kerngruppe Spezifikation diskutieren möchten. Sämtliche Punkte zur Spezifikation, die aus unserer Sicht nicht ganz klar spezifiziert worden sind, haben wir hier gesammelt: https://code.google.com/p/extra-standard/wiki/eXTraSpecIssues

Viele Grüße

Lofi Dewanto.

[Oliver Staudt]

Danke für den Hinweis.

[Florian Stratil]

Diesbezüglich habe ich mich auch nochmal mit den Entwicklern des Servers unterhalten. Scheinbar war auch ein Problem, dass der Parser, den IBM innerhalb des WebSphere-Servers ausliefert nicht ganz sauber arbeitet. Der Austausch des Parsers gegen einen anderen hat zu einem besseren (Nicht gut, aber besseren) Ergebnis geführt. Wenn ich die Sourcen habe, kann ich da dann auch mehr zu sagen.