TRADElube 1.2.0.57 Release Notes

Release Datum:

Die Entwicklungen in der Version 1.2.0 und 1.2.1 sind soweit grundsätzlich abgeschlossen und beschränkt sich nur noch auf Bugfixes und kleinere Optimierungen. Die Entwicklung größerer Features sind in der übernächsten Hauptversion 1.3.0 in Arbeit.

Die Release Notes konzentrieren sich auf die wichtigsten Themen, unabhängig vom Entwicklungsaufwand, jedoch basierend auf dem Informationsgehalt. Zusätzlich erfolgen immer auch kontinuierlich interne Überarbeitungen der Softwarearchitektur, Performance und Systemstabilität, die nicht explizit erwähnt werden.

Übertragung von fehlerhaften Einträgen wiederholen

Fehlerhafte Übertragungen werden nach einer gewissen Zeit gedrosselt. Aktuell nachdem der Fehler bereits 48 Stunden lang existiert und eine Behebung trotz der zahlreichen wiederholten Übertragungen nicht funktioniert hat. Ab dann wird die Übertragung nur noch alle 2 Stunden einmal probiert (diese Zeiträume sind aktuell so festgelegt, das kann sich aber künftig noch ändern). Grundsätzlich ist diese Drosselung bei der automatischen Übertragungen sehr sinnvoll, um das System nicht sinnloserweise die ganze Zeit mit fehlerhaften Übertragungen auszulasten.

Wenn man eine Aufgabe jedoch manuell ausführt, dann kann dieses Konzept ein großes Missverständnis sein, wenn man sich z. B. wundert, warum ein Fehler wie z. B. ein Verbindungsproblem zum Shop nicht weggeht, obwohl man das dahinterliegende Problem zwischenzeitlich behoben hätte.

Deshalb wird ab jetzt die oben beschriebene Drosselung nicht mehr durchgeführt, wenn eine Aufgabe manuell in der Oberfläche von TRADElube über die Schatlfläche "Ausführen" ausgeführt wird. Auch fehlerhafte Übertragungen werden in diesem Fall also ab nun grundsätzlich immer nochmal wiederholt, egal wie lange es diesen Fehler bereits gibt.

Workload Überarbeitung

TRADElube ist ein verteiltes System und läuft somit auf mehreren bzw. vielen Servern innerhalb eines Clusters (Kubernetes) aufgeteilt auf verschiedene Dienste (Pods & Container): Backend, API, Worker etc.. Jeder Dienst läuft auch wiederrum vielfach bzw. redundant. Ein offensichtlicher Zweck dieser Architektur ist zum einen die Ausfallsicherheit und zum anderen auch die Lastverteilung wodurch eine Skalierbarkeit der Anwendung auf viele Kunden möglich ist. Sobald das System an seine Grenzen kommt, können also einfach weitere Server ergänzt und die Anzahl Dienste (bzw. Replikate) erhöht werden.

Die Hintergrunddienste (Worker) im Speziellen verteilen die Clients (TRADElube-Mandanten) möglichst gleichmäßig auf viele Worker-Instanzen, welche dann rund um die Uhr die Aufgaben in TRADElube im Hintergrund ausführen. Diese Verteilung des "Workloads" wurde nun vollumfänglich überarbeitet. Grund Nr. 1 war die Notwendigkeit sog. Routing-Regeln, wodurch nun einzelne Clients (TRADElube-Mandaten) z. B. von einzelnen Servern ausgeschlossen werden können.

Warum das Ganze?

In Einzelfällen kann es vorkommen, dass einzelne Server (bzw. dessen öffentliche IP) von fremden Webspaces geblockt werden. Dann ist z. B. kein Zugriff von TRADElube auf das Shopsystem möglich. Das ist dann definitiv kein Problem von TRADElube, sondern ein Problem des Webspaces bzw. des Shopsystems, da müssten z. B. die geblockten IPs durch Whitelisten freigegeben werden, bzw. können die Probleme auch komplizierter sein.

Sollte der Webhoster nicht in der Lage sein, dieses Problem zu lösen, dann gibt es ab jetzt mit diesen neuen Routing Features in TRADElube eine Workaround-Möglichkeit, indem man den Client von den betroffenen Servern ausschließt und wodurch die Hintergrunddienste eines Clients dann immer automatisch auf einem anderen Server eingeplant werden.

Zum aktuellen Zeitpunkt geht das nur für die Hintergrunddienste. Das manuelle Ausführen von Aufgabe im TRADElube Backend ist davon nicht eingeschlossen, da kommt es drauf an auf welchem Server man zufällig gelandet ist. Da kann dann ein Neuladen der Seite helfen, um dann dadurch wieder zufällig auf einem anderen Server zu landen.