Wer sich initial mit dem Thema Multithreading auseinandersetzt, dem wird stets im Zusammenhang mit Multithreading das Thema „thread-safe“ über den Weg laufen. Mit Threadsicherheit bzw. Threadsafe ist gemeint, dass eine Klasse oder Methode so aufzubauen ist, dass eine parallele Abarbeitung gewährleistet ist und sich die parallelen Stränge nicht gegenseitig behindern oder manipulieren können, vgl. hierzu auch http://de.wikipedia.org/wiki/Threadsicherheit.

Mit bestimmten Programmierpraktiken kann man die parallele Abarbeitung unterbinden, so z.B. durch die Deklaration einer Methode als synchronized, hiermit macht man eine Methode auch „threadsicher“ aber in einem anderen Sinne, mit der Konsequenz, dass alle Threads nur nacheinander diese Methode durchlaufen können (die Threads können eine Methode nur synchron durchlaufen), was im Verbund des Application Layers dazu führt, dass die Multithreadingfähigkeit aufgehoben bzw. blockiert wird.

Wird zur Laufzeit, nach Einspielen eines Plugins, ein Performanceeinbruch registriert, so kann ein synchronized Block des Plugins hierfür die Ursache sein. Im schlimmsten Fall kann es durch einen synchronized Block sogar zu Deadlock-Situationen kommen, etwa wenn innerhalb eines synchronized Blocks eine API-Methode aufgerufen wird, die wiederum in den synchronized Block läuft. In diesem Fall hängt der Thread ewig (bis der Server neu gestartet wird). Synchronisierte Blöcke sollten daher nach Möglichkeit überhaupt nicht benutzt werden. Wenn es sich gar nicht vermeiden lässt (als letzte Lösung nach Ausschöpfung aller anderen Möglichkeiten), sollte der synchronized Block nur für die geringstmögliche Anzahl von Zeilen benutzt werden.

java member variables

Eine Variable als Klassen- bzw. „Member variable“ anzulegen ist in einer Multithreading-Umgebung nur dann sinnvoll, wenn der Inhalt der Variablen für alle Requests dieses Plugins IMMER gleich ist, der Inhalt der Variable also nicht potentiell zur Laufzeit verändert wird. Im benutzten Speicher der JVM gibt es auch bei mehreren Instanzen einer Plugin-Klasse nur EINEN Bereich, in dem der Wert der Variablen abgelegt wird. Werte wie z.B. die konkreten Verbindungsparameter zu einer Datenbank oder die konfigurierten Werte für die Längen- und Breitenangaben einer Rendition können mit Member-Variablen abgelegt werden.

java local variables

In einer Multithreading Umgebung sollte man immer mit lokalen Variablen arbeiten. Lokale Variablen im Java-Sinne sind Variablen, die innerhalb einer Methode deklariert und gesetzt werden. Ist es notwendig, Daten über mehrere Methodenaufrufe innerhalb des Plugins zu halten, so sollte man hier mit der Klasse ThreadLocal arbeiten. Vereinfacht gesagt, ist die Klasse ThreadLocal ein Container, der für jeden Thread erzeugt wird und auch sicherstellt, dass jeder Thread seinen Container hat und auch nur auf diesen zugreifen kann. Konkrete Werte können in diesen Container geschrieben und auch wieder ausgelesen werden. Technisch ist es so, dass der „ThreadLocal Container“ solange Bestand hat, wie der Thread Bestand hat.

Wird ein Plugin aufgerufen und der Plugin-Code selber führt Operationen auf der Schnittstelle aus, kann es potentiell zu Endlosschleifen kommen, wenn sich das Plugin dadurch immer wieder selbst aufruft. Beispiel: Ein Plugin, welches durch einen updateProperties(…) Service-Request getriggert wird und selber im Ablauf des Plugin-Codes ein updateProperties(…) aufruft. Um in diesem Fall nicht in eine Endlosschleife zu geraten, ist die Empfehlung, den ersten, initialen Aufruf des Plugins mittels des ThreadLocal-Mechanismus zu speichern. Beim erneuten Aufruf des Plugins, getriggert durch den selbst initiierten updateProperties(…) Service-Request, wird die ThreadLocal Variable ausgelesen und bei Vorhandensein des speziellen Attributs die API Methode nicht erneut ausgeführt.

Prinzipieller Ablauf innerhalb eines Plugins, welches auf updateProperties(…) reagiert und seinerseits aufgrund eines Attributwertes ein anderes Attribut setzt:

Wichtig in diesem Kontext ist, zu beachten, dass Methodenaufrufe eines Clients, welche nacheinander über dieselbe Session abgesetzt werden, potentiell immer durch denselben Thread im Server ausgeführt werden. Dadurch steht den Methoden derselbe ThreadLocal Kontext zur Verfügung und auch die Plugins reagieren bei den Aufrufen dementsprechend.

Das folgende Negativ-Beispiel eines ServiceInvocationHooks zeigt, wie man eine Member-Variable falsch benutzt und dadurch eine Klasse implementiert, die nicht thread-safe ist:

Wird statt der Member-Variable eine lokale Variable benutzt, ist die Klasse thread-safe:

Abschließend noch ein Beispiel zur Vermeidung von Endlosschleifen und zum korrekten Umgang mit ThreadLocal:

Hinweis: Ab Version 7.1 bietet der PluginRuntimeService eine Methode an, die die Rekursionstiefe innerhalb eines ServiceInvocationHooks oder eines ServiceMethodInterfereHooks bzw. ServiceMethodOverwriteHooks zurückliefert. In gewissen Szenarien kann es nützlich sein, diese Information in ThreadLocal zu speichern, z.B. wenn in einem ServiceInvocationHook in der before-Methode Werte gespeichert werden sollen und in der afterReturning-Methode ausgewertet werden sollen:

Mit Hilfe dieser Vorgehensweise kann quasi eine Brücke geschlagen werden von der before- zur dazugehörenden afterReturning-Methode.

Ab Version 7.6 liefert der Server die Klasse PluginSynchronizationContext mit aus, die ThreadLocal- Member enthält. Man kann sich dieser Klasse bedienen, um nicht selber ThreadLocal-Variablen definieren zu müssen. In Version 7.10 liefert der Server innerhalb der Klasse z.B. eine Konstante für eine PrincipalId mit aus. Man kann mit Hilfe dieser Konstante eine PrincipalId innerhalb eines Plugins setzen und in einem anderen Plugin auswerten. Beispiel:

Auswertung innerhalb eines anderen Plugins:

Besteht die Notwendigkeit, im Fehlerfall eine Information auch nach Zurückrollen der Transaktion zu erhalten, kann man sich des Application Layer TransactionCallback Verfahrens bedienen. Eine benutzerdefinierte Transaktion wird implizit über das Java-Interface TransactionCallback < E > gesteuert. Eine Klasse, die dieses Interface und die dazugehörige Methode doInTransaction() implementiert, kann Aufgaben (z.B. updateProperties(…)) unabhängig von der äußeren Transaktion in einer eigenen, inneren Transaktion ausführen. Alle Methodenaufrufe innerhalb der doInTransaction() Methode werden in der inneren Transaktion ausgeführt. Der PluginRuntimeService bzw. WorkflowRuntimeService enthalten eine Methode execute(…), die als Parameter eine Implementierung von TransactionCallback erwartet. Beim Aufruf von execute wird implizit

Als Deadlock wird in der Informatik ein Zustand bezeichnet, bei dem mehrere beteiligte Prozesse Ressourcen halten und gleichzeitig auf eine weitere Ressource warten, die schon von einem anderen beteiligten Prozess gehalten wird. Auf diese Weise blockieren sich die Prozesse gegenseitig und alle beteiligten Prozesse warten ewig, da kein Prozess eine benötigte Ressource freigibt.

Konkrete Deadlocks werden von den Datenbanken in der Regel als solche erkannt und selbstständig durch die Datenbank aufgelöst. In der Regel sind zwei Transaktionen beteiligt, von der eine von der Datenbank als Deadlock-Opfer ausgewählt und automatisch zurückgerollt wird. Man erkennt dies daran, dass im Log-File eine entsprechende Exception protokolliert wird, in der die Auswahl des Deadlock-Opfers gemeldet wird.

Das Problem von Deadlocks kann in Multithreading-Umgebungen potentiell immer auftreten. Theoretisch ließen sich Deadlocks vermeiden, wenn alle Prozesse ihre benötigten Ressourcen immer in der gleichen Reihenfolge anfordern würden. Im Falle des nscale Server Application Layers lässt sich dies leider nicht realisieren, da die Reihenfolge des Zugriffs auf Datenbank-Tabellen durch das eingesetzte Hibernate-Framework bestimmt wird und nur bedingt vorgegeben werden kann. Je nach angebundener Datenbank kann das Problem von Deadlocks mehr oder weniger stark ausgeprägt sein, dies hängt von der verwendeten Lock-Strategie des verwendeten Datenbank-Dialekts ab. Vor allem der Microsoft SQL Server lockt Tabellen sehr restriktiv, daher ist unter dieser Datenbank vermehrt mit Deadlocks zu rechnen. Falls dies gehäuft auftritt, sollte geprüft werden, ob der Snapshot Isolation Level (sogenannter Oracle-Modus) benutzt werden kann.

Wie gesagt können Deadlocks von der Datenbank in der Regel selbstständig erkannt und aufgelöst werden. Es gibt aber Fälle, in denen die Datenbank nicht in der Lage ist, diesen automatisch aufzulösen, weil er nicht als (Datenbank) Deadlock klassifiziert werden kann. In diesem Fall sprechen wir von einem Blocking Lock. Ein Blocking Lock tritt z.B. auf, wenn eine äußere Transkation eine Ressource hält, die auch von einer inneren Transaktion (z.B. in einem TransactionCallback) benötigt wird. Ist so ein Zustand erreicht, hängen beide Transaktionen ewig (bis evtl. ein Transaktions-Timeout zuschlägt).

Man kann durch Einhaltung gewisser Designempfehlungen die Wahrscheinlichkeit eines Blocking Locks aber gering halten. Als Faustregel kann man sagen, dass der TransactionCallback-Mechanismus bzw. das Starten von benutzerdefinierten Transaktionen innerhalb des Plugins nur sehr bedacht erfolgen sollte und nur da, wo es sinnvoll und notwendig ist. Erfahrungsgemäß treten Blocking-Lock-Situationen immer nur in Verbindung mit dem TransactionCallback-Mechanismus auf.

Wenn man mit dem TransactionCallback-Mechanismus (benutzerdefinierte Transaktionen) arbeitet, sollte man folgende Grundregeln beachten bzw. seinen bestehenden Code dahingehend anpassen: Der TransactionCallback-Mechanismus kann immer dann problematisch sein, wenn schreibende Operationen (z.B. updateProperties(…)) im Plugin und auch innerhalb des TransactionCallback Blocks (setzen eines Fehlerstatus) passieren, vor allem wenn dies gleiche Tabellen und Zeilen betreffen. Ändern Sie ihren Code nach Möglichkeit dahingehend ab, dass schreibende Operationen in der äußeren Transaktion erst nach dem TransactionCallback Block aufgerufen werden. Technisch sorgen Sie so dafür, dass es zu keinen Blocking-Lock-Situationen auf Seiten der Datenbank durch sich gegenseitig blockierende Schreiboperationen kommen kann.

Die folgenden Abbildungen enthalten Fallbeispiele und Empfehlungen, wie der Plugin-Code angepasst werden kann, um die Wahrscheinlichkeit von Blocking Locks zu minimieren.

Das Fallbeispiel aus Abbildung 3 ist der Idealfall, hier wird es nie zu Blocking-Lock-Situationen kommen. Allerdings ist es fraglich, ob diese Vorgehensweise auch praxisrelevant ist, da es vermutlich eher nötig sein wird, schon vor Ausführung eines TransactionCallbacks schreibend auf die Datenbank zugreifen zu müssen. Daher ist das Fallbeispiel aus Abbildung 2 die empfohlene Vorgehensweise, auch hier wird es kaum zu Blocking-Lock-Situationen kommen (es sei denn, Hibernate führt ausgerechnet vor Ausführung der inneren Transaktion ein auto-flush aus, dies dürfte aber nur ein theoretisches Problem sein).

Kurz gesagt kann man folgende Strategie ausgeben: Zwischen einer schreibenden Operation der äußeren und einer schreibenden Operation der inneren Transaktion darf kein Lesevorgang auf demselben Datenbestand stattfinden. Was derselbe Datenbestand ist, ist vom verwendeten Datenbank-System abhängig, es kann z.B. die selbe Tabelle oder die selbe Zeile bedeuten, je nachdem, wie restriktiv die Datenbank lockt. Grundsätzlich ist es erstrebenswert (wenn es die Logik des Plugins zulässt), dass alle lesenden Zugriffe vor allen schreibenden Zugriffen stattfinden, da so auch Sperren auf Datenbank-Tabellen möglichst kurz gehalten werden und die Gefahr von Deadlocks verringert wird.

Seit Version 7.3 unterstützt der Server eine erweiterte Form des ServiceInvocationHooks, den OutOfContextServiceInvocationHook. Dessen Methoden werden außerhalb der eigentlichen Transaktion eines Service-Requests aufgerufen und eignen sich daher auch, bei zurückgerollten Transaktionen Fehlerzustände zu schreiben. Damit stellt der OutOfContextServiceInvocationHook eine Alternative zu TransactionCallbacks dar. Der Vorteil ist, dass Blocking Locks vermieden werden.

In der Praxis ist es oft so, dass mit weiteren Kundenanforderungen auch neue Versionen von bestehenden Plugins notwendig werden. Um zweifelsfrei belegen zu können, welche Version des Plugins aktuell im Server seinen Dienst tut, ist dies nur durch geeignete Protokollausgaben innerhalb des Plugins sinnvoll möglich.

Es ist technisch nicht möglich, auf generischem Weg automatisch durch den Application Layer für eine entsprechende Protokollierung zu sorgen. Diese Verantwortung liegt bei dem Entwickler des Plugins.

Unsere Empfehlung ist, eine Logausgabe entsprechend dem Beispiel aufzubauen und diese während der Initialisierung des Plugins (Methode afterConfigured) grundsätzlich mit auszugeben, zusätzlich in der Protokollierungsstufe debug oder trace bei jedem Methodenaufruf des Plugins. Somit ist immer gewährleistet, zu Beginn aber auch zur Laufzeit, über die konkrete Version des Plugins zweifelsfrei informiert zu sein.

Es versteht sich von selbst, dass die Version des Plugins bei jeder Anpassung des Plugin-Codes entsprechend angepasst werden muss!

Werden die Plugins als JAR oder ZIP-Archive geladen, so kann man diese mit Versionsnummern versehen, z.B. myPlugins-1.0.jar.

Ab Version 7.2 können sowohl Plugins als auch die darin benutzten Klassen und Dateien Metainformationen enthalten, wie z.B. den Ersteller, die Versionsnummer oder das Änderungsdatum. Diese Informationen können bei Bedarf ausgelesen und mit ausgeloggt werden. Beispiel zum Lesen der PluginInfo:

Eine detaillierte Beschreibung der Möglichkeiten inkl. einer konkreten Empfehlung, welche Felder wie zu setzen sind, finden Sie in der offiziellen Dokumentation zum nscale Administrator.

Wir empfehlen, immer den Standard Application Layer Logging Mechanismus zu verwenden. Eine Logger-Instanz erhält man, indem sie in der Klasse instanziiert wird:

Es sollten mindestens so viele Logausgaben implementiert werden, dass alle Schritte innerhalb des Plugins in der Protokolldatei erscheinen und man ohne Code den Ablauf des Plugins nachvollziehen kann.

Unsere Empfehlung ist es, die Version des Plugins während der Initialisierung als INFO Message herauszugeben und Informationen zum Ablauf des Plugins als DEBUG oder TRACE Message.

Logausgaben mittels System.out.println() sind auf jeden Fall zu vermeiden. Solche Ausgaben landen in der Standardausgabe, was beim nscale Server Application Layer die Server-Protokolldatei ist. Dieser Befehl sollte höchstens in der Debug-Phase benutzt werden und hat in einem produktiven Plugin nichts verloren!

Seit Version 7 unterstützt Java das try-with-resources Statement, mit dessen Hilfe Objekte automatisch geschlossen werden. So ein Statement kann für Klassen benutzt werden, die das AutoCloseable Interface implementieren. Es bekommt einen unsichtbaren finally Block, in dem die close Methode aufgerufen wird. In Advanced Connector Version 7.8 erweitern die beiden Interfaces ExtendedContent und Session das AutoCloseable Interface. Damit sind z.B. folgende Statements möglich:

Meistens sollen Plugins nur auf bestimmte Service-Methoden reagieren und der erste Schritt des Plugins besteht oft darin zu erkennen, ob das Plugin greifen soll oder nicht. Bei der Ermittlung der Zuständigkeit sollte unbedingt darauf geachtet werden, dass zuerst die weniger zeitaufwändigen Kriterien überprüft werden und erst am Ende die zeitaufwändigen. Es sollte klar sein, dass z.B. ein ServiceInvocationHook bei JEDEM Service-Request durchlaufen wird, d.h., wenn schon die erste Zeile ein teurer Methodenaufruf ist, wird JEDER Request ausgebremst.

Schlecht ist also z.B. folgende Vorgehensweise:

Richtig ist folgende Reihenfolge:

Jeder Service-Request ist potentiell teuer. Die Anzahl der Requests sollte minimiert werden, insbesondere sollte es keine redundanten Requests geben. Es muss auch bedacht werden, dass vor allem Service-Requests auf dem RespositoryService und in etwas geringerem Maße WorkflowService teuer sein können, da hier mit Massendaten gearbeitet wird. Weniger bedenklich sind Aufrufe des ConfigurationService, da die Konfiguration komplett im Speicher gehalten wird und weniger Datenbank- Statements benötigt werden (wenngleich z.B. für die Rechteprüfung doch einige abgesetzt werden müssen).

Es folgt wieder ein Negativbeispiel aus dem täglichen Leben:

Hier wird bei n vorhandenen Objektklassen n + 1 mal redundant die Server-Methode getObjectclasses(…) aufgerufen, korrekt wäre es folgendermaßen:

Bei dieser Vorgehensweise wird der Server nur einmal angefragt.

Da dieses Beispiel nur den ConfigurationService betrifft, sind die Konsequenzen nicht ganz so dramatisch. Fatal ist aber z.B. folgendes Negativbeispiel für den RepositoryService:

Hier wird eine Suche abgesetzt und für jede gefundene Ressource wird mittels getProperties der Anzeigename geholt. Die Konsequenz ist, dass bei einem ResultSet mit 1000 Treffern insgesamt 1001 Select-Statements abgesetzt werden, benötigt würde aber nur ein Select-Statement, wenn die benötigten Attribute gleich mit der Suche abgefragt würden:

Fazit: Der Entwickler eines Plugins muss sich Gedanken machen, welche Informationen er benötigt, um diese Informationen dann mit der geringstmöglichen Anzahl von Service-Requests abzufragen.

Der wohl teuerste Methodenaufruf ist eine Suche im RepositoryService. Auch hier gibt es ein paar Regeln, die unbedingt zu beachten sind, um eine zusätzliche, unnötige Belastung des Servers zu vermeiden.

Erstellt man ein Plugin für Custom Computed Properties, das die Default-Implementierung DefaultCustomComputedIndexingPropertyDefinitionsHandler erweitert, können für die Berechnung zwei Methoden überschrieben werden, die Methoden compute und batchCompute. Wenn Zwischenergebnisse von Berechnungen wiederverwendet werden können, sollte die Methode batchCompute überschrieben werden, da dies eine deutliche Performance-Steigerung bewirken kann. Beispiel: es soll eine Property erzeugt werden, die den Anzeigenamen des Eltern-Ordners zurückgibt. Eine Implementierung von compute könnte so aussehen:

Diese Implemtierung kann sehr inperformant sein, da für viele Ressourcen immer wieder der gleiche Anzeigename neu berechnet wird (für alle, die den gleichen Eltern-Ordner haben). Die Implementierung kann verbessert werden, wenn die Methode batchCompute benutzt wird:

Ab Version 7.13 bietet der nscale Server Application Layer im CommonRuntimeService die Methode setUseInitialContext(boolean) an. Wenn der Wert auf true gesetzt wird, finden alle nachfolgenden Methoden-Aufrufe innerhalb des Plugins im Kontext des Benutzers statt, der initial den Service-Request abgesetzt hat (z.B. im Cockpit-Client). Wird der Wert wieder auf false gesetzt, geschehen nachfolgende Methoden-Aufrufe wieder im System-Kontext. Das Setzen des initialen Kontexts ist nicht rekursiv, d.h. wenn ein Methoden-Aufruf im initialen Kontext wiederum von einem Plugin abgefangen wird und in diesem Plugin weitere Methoden aufgerufen werden, werden diese Methoden wieder im System-Kontext ausgeführt. Anders ausgedrückt: jedes Plugin ist selber dafür verantwortlich, den initialen Kontext zu setzen, das Plugin erbt das Setzen des initialen Kontexts nicht von der aufrufenden Methode.

Ab Version 7.15 steht im CommonRuntimeService zusätzlich die Methode isInitialContextSet() zur Verfügung. Mit Hilfe dieser Methode kann innerhalb eines Plugins abgefragt werden, ob für den aktuellen Methodenaufruf der initiale Kontext gesetzt wurde, d.h. ob vor dem Aufruf der Methode innerhalb eines Plugins die Methode setUseInitialContext(true) aufgerufen wurde.

Unter nscale Cluster wird der Clusterverbund mehrerer nscale Server Application Layer verstanden, die auf Basis eines zentralen, gemeinsamen Datenbank Schemas konfiguriert sind oder anders ausgedrückt: alle nscale Server Application Layer, die auf die gleiche Datenbank bzw. das gleiche Schema zugreifen, bilden einen Clusterverbund.

Die .NET AdvancedConnector Schnittstelle bietet einen Service-Adapter an, um bequemer diese Möglichkeit nutzen zu können. Der Service-Adapter ermöglicht es, ein Interface zu definieren, für das die Schnittstelle eine Proxy-Implementierung erstellt, das auf die generische Methode invokeGenericMonitoringMethod delegiert. Das Interface muss das zur Verfügung gestellte Interface IAdapter erweitern. Hinweis: in der Core-Variante des .NET AdvancedConnectors steht dieser Adapter nicht zur Verfügung.

Beispiel:

Anwendung im Client:

Funktionalitäten, die mittels der Methode invokeGenericMonitoringMethod aufgerufen werden, können auch asynchron ausgeführt werden. Der Server liefert dazu seit Version 7.12 die Klasse com.ceyoniq.nscale.al.core.plugin.hook.AsynchronousMethodExecutor aus. Instanziiert man einen ServiceInvocationHook, der diese Klasse benutzt, dann werden alle Aufrufe von invokeGenericMonitoringMethod, dessen Methoden-Name den Präfix async oder async_ hat, asynchron ausgeführt. Im obigen Beispiel reicht also ein Aufruf der Form:

Eine Methode, die asynchron ausgeführt wird, hat als Rückgabewert natürlich immer den Wert null.

Die folgende Abbildung gibt einen Überblick über die am häufigsten benutzten Plugin-Arten. Es werden die von den Plugins zu implementierenden Interfaces (Handler der Plugins) und deren Methoden dargestellt.

Beim Start des nscale Server Application Layers (bzw. Reinitialisierung der Plugins) werden die Initialisierungsmethoden afterConfigured() und afterConfigured(PluginExecutionContext) (falls das Plugin das Interface ContextAwarePluginHandler implementiert) eines jeden Plugins aufgerufen. Die Reihenfolge ist fest definiert (siehe Abbildung unten). Wird der Application Layer heruntergefahren (bzw. bei Zerstörung der alten Plugins vor der Reinitialisierung), werden analog die Methoden destroy() und destroy(PluginExecutionContext) (falls das Plugin das Interface DestroyableContextAwarePluginHandler implementiert) aufgerufen.

Legende der häufigsten Plugin-Arten:

Nachfolgend sieht man die Reihenfolge der Abarbeitung unterschiedlicher Plugins bei Aufruf einer Service-Methode (z.B. createDocument(…)).

Siehe Endlosschleifen

Siehe Deadlocks / Blocking Locks

Als goldene Regel kann man sagen, dass zwischen einer schreibenden Operation der äußeren und einer schreibenden Operation der inneren Transaktion KEIN Lesevorgang auf demselben Datenbestand stattfinden darf und nach Möglichkeit alle lesenden Zugriffe vor den schreibenden stattfinden sollten.

Die Plugin-Factory von nscale Server Application Layer kopiert alle in Plugins enthaltenen externen Bibliotheken (engl. Libraries, *.dll-Dateien unter Windows, *.so-Dateien unter Unix) in das native lib -Verzeichnis. Es hat sich gezeigt, dass es im Umgang mit DLLs und dem Nachladen von Klassen zur Laufzeit oftmals zu Schwierigkeiten kommt. Im Zweifelsfall sollte auf eine der unten beschriebenen Alternativen ausgewichen werden.

Nach Möglichkeit sollten einzelne Java *.class Dateien erst in eine *.jar Datei gepackt und dann mit nscale Administrator hochgeladen werden. Aufgrund der internen geschachtelten Classloader Logik ist dieses Vorgehen sehr viel performanter.

Hintergrund:
Wenn viele einzelne Java *.class Dateien existieren, müssen diese alle explizit mittels nscale Classloader nscale Server Application Layer bekannt gemacht werden. Je mehr Dateien existieren, umso länger dauert der Vorgang.

Werden sehr viele zusätzliche Klassen und Pakete benötigt, so können diese über einen anderen Weg nscale Server Application Layer dauerhaft bekannt gemacht werden. Hierzu besteht die Möglichkeit, den java.classpath Parameter in der service.conf Datei zu erweitern. Dies hat zur Konsequenz, dass über diesen Weg hinzugefügte Klassen und jar-Dateien sofort zur Verfügung stehen und vor allem nicht bei jeder PluginsSetting Änderung immer wieder (s.o.) nachgeladen werden müssen.

Aber:
Beachten Sie, dass manuelle Änderungen am java.classpath Parameter beim Upgrade-Prozess nicht berücksichtigt werden. Beim Upgrade-Prozess werden manuelle Änderungen überschrieben und die Änderung muss anschließend erneut durchgeführt werden. Zudem ist zu beachten, dass auf diesem Wege hinzugefügte Klassen und Packages nur auf diesem Knoten verfügbar sind. Beim Clusterbetrieb bzw. im Zweifelsfall ist diese manuelle Erweiterung für jeden(!) Knoten durchzuführen!

Aus diesem Grund ist dieses nicht der empfohlene Weg, obwohl er unter bestimmten Umständen sinnvoll sein kann.

nscale Server Application-Layer nimmt alle Bibliotheken, die im Verzeichnis <InstallDir>/lib/ext liegen, mit in den Standard-Anwendungs-Classloader auf. Damit entfällt das Anpassen der java.classpath Einstellung in der Datei service.conf.

Dieses Vorgehen soll nicht den Standard-Plugin-Mechanismus ersetzen. Allerdings hat es sich gezeigt, dass es mit dem Plugin-Classloader Probleme geben kann: