Prozessbasierte Architektur Neu ab S 39.5.16

info Information
  • Das Prozessmodell des Servers wurde ab Server 39.5.16 dahingehend geändert, dass jede Client-Sitzung in einem isolierten Prozess abläuft und weder andere Sitzungen noch den gesamten Serverbetrieb gefährden kann.

Motivation

Durch die Änderungen der Prozessarchitektur gibt es folgende Vorteile
  • Stabilität: Sitzungsabbrüche haben keine Auswirkungen auf den gesamten PLANTA-Server, da die einzelnen Sitzungen nun getrennt voneinander sind.
  • Geringere Ressourcenkonkurrenz: Da exklusive Ressourcen, wie z.B. der Python-Interpreter, nicht mehr nur von einer Sitzung in Anspruch genommen werden, kommt es zu Performance-Verbesserungen.
  • Vermeidung von unnötiger Ressourcenbelegung: Bei einer Speicherschutzverletzung kann die entsprechende Session sofort gefahrlos beendet werden. Dadurch steht dieser Speicher dem Gesamtsystem sofort wieder zur Verfügung.

Durch die oben beschriebenen Punkte ist die neue Architektur daher auch in Zukunft deutlich robuster gegen unvorhersehbare Fehler.

Änderungen

  • Jede Client-Sitzung wird innerhalb eines Prozesses ausgeführt (statt innerhalb eines Threads, wie es bisher der Fall war).
  • Die für die Datenbank-Kommunikation und Sitzungsverwaltung verantwortliche Schicht ist rein Java-basiert.
  • Parallel hierzu läuft eine rein native Komponente zur Annahme von Client-Verbindungen und Verteilung des DataDictionary (Master).
  • Die ebenfalls native Sitzungskomponente, die für jede Client-Verbindung erstellt wird, übernimmt z.B. die Authentifizierung, den Modulaufbau und die allgemeine Ereignisverarbeitung.
  • Zur Kommunikation zwischen den Komponenten nutzt der PLANTA Server über Protocol Buffers serialisierte Nachrichten, die über ausschließlich lokal ansprechbare Netzwerk-Sockets ausgetauscht werden.

Multithreaded-Architektur Prozessbasierte Architektur

Auswirkungen

  • Bei erfolgreichem Start des Servers laufen nun statt zwei Prozessen (service wrapper und PlantaServer) mindestens drei Prozesse: service wrapper, PlantaServer, Master (DataDictionary, Verbindungsannahme) und für jede Sitzung ein weiterer Prozess.
  • Da die Kommunikation über Sockets erfolgt, muss u.U. die Maximalanzahl von Dateideskriptoren angehoben werden.
  • Sitzungen können über Betriebssystemmittel (kill, Task-Manager) auch einzeln beendet werden.
  • Ein Sitzungsabsturz/-abbruch hat durch die Prozessraumtrennung keine direkten Auswirkungen auf andere Sitzungen (z.B. Speicherverletzungen etc.).
  • Statt eines gemeinsam genutzten Python-Interpreters ist nun in jede Sitzung ein Interpreter integriert.
    • Insbesondere bei hoher paralleler Nutzung des Servers führt dies zur Verbesserung der Performance, da immer ein exklusiver Zugriff gegeben ist.
    • Der Interpreter kann nicht mehr zur gemeinsamen Nutzung von Daten verwendet werden; gleichzeitig verhindert dies fehlerhafte bzw. missbräuchliche Applikation, die o.g. Speicherverletzungen hervorrufen können.
Topic attachments
I Attachment Action Size Date Who Comment
pngpng multithreaded.png manage 87.2 K 2015-05-26 - 20:32 UnknownUser multithreaded architecture sketch
pngpng processes.png manage 88.5 K 2015-05-26 - 20:32 UnknownUser process model sketch
Topic revision: r8 - 2016-09-19 - 17:51:27 - IrinaZieger








 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten