Java-Applikation als Server-Dienst

[RobertPic]

Was das Design angeht, kann ich mich mit der Tomcat Geschichte bei der Abwägung von pros und cons nicht so ganz anfreunden.
cons:
- im Appserver sollte man keine Threads erzeugen
- letzteres kann Probleme verursachen, falls Tomcat anderweitig verwendet wird und unter Last stehet
- was passiert eigentlich wenn der Toolbox Krempel die JVM erfolgreich mürbt?
- für den Dienst alleine zuviel Overhead und Aufwand
- Automatisierung für Start bringt einem noch HTTP ins Haus

als echtes pro steht dem eigentlich nur die Transparenz gegenüber, dass das auf allen Büchsen gleich funzt

Die meisten Argumente kann ich nachvollziehen, aber die Empfehlung

im Appserver sollte man keine Threads erzeugen

ist mir noch nicht untergekommen - maximal das Dauerläuferthreads in Servlets problematisch sein können. Ansonsten habe durchwegs Anregungen und Beispiele für Threads im Webserver gefunden. Und für was gibt es sonst Listener in der web.xml?

Ansonsten kann ich nur sagen, dass ich hier ein paar 24x7-Dienste laufen habe, der längste davon ein halbes Jahr (inkl. Toolboxtreibern für DataQueue, JDBC).

Das mit dem Overhead ist sicher richtig, deshalb verwende ich das (noch) nicht auf der iSeries - bis zum nächsten Hardwaresprung.

Als "halber" Webprogrammierer habe ich meine Dienste freilich schon um Editor für (Properties + xml), Status und Logabfragen erweitert.

Ob nur Dienste für Tomcat den Aufwand rechtfertigen, ist natürlich (wie Dieter Bender schon anmerkte) nicht gesagt.

In meiner Umgebung (Win/Linux/iSeries + fremde + eigene Webanwendungen) war der Umstieg auf Tomcat ein leichtes.

PS. Hier mal mein aktuelles Javaprojekt (Beta), welches ich auch mal herzeigen kann:

http://odtemp.ath.cx/OdKatalog/tree.zul#gr_0
(der AS/400-Teil ist von außen aber nicht erreichbar)

[BenderD]

Hallo,

der ServletContext ist normalerweise der Ort, wo man die Objekte hält, die Application Scope haben, dazu gehören in aller Regel auch teure Objekte, wie Connection Pools. Zur Verbesserung der Antwortzeiten lädt man die meist dann bereits beim Start der Applikation, genauso wie bestimmte Caches; auf altmodische Art über die init Variante eines Autoload Servlets, oder aber über die Context Listener.

Erzeugung von Threads ist normalerweise dem Container überlassen (der das nebenbei bemerkt. besser kann, der verwendet Pools, kümmert sich um Leichen, etc.) und wird nur von diesem ausgeführt, so ganz trivial ist das ja auch nicht, wg. Deadlocks zum Beispiel und eine vollgefressene JVM des Tomcat, oder AppServers ist natürlich der GAU. In einer reinen Java Umgebung ist das unproblematisch, da braucht man keine Hand gestrickten Dienste, sondern regelt das über einen ServletRequest, eine EJB oder einen WebService, letztere beiden wären dann das was man täte und da brauchts keine eigen erzeugten Threads.

Im Mixfall RPG/Java haben wir ja den fatalen Fall, dass wir über den DTAQ Mechanismus ja gerade verhindern wollen, in jedem Job eine JVM zu starten, deswegen scheiden da session Beans leider aus. Am saubersten wäre es m.E. einen relativ schlanken Adapter zu schreiben, der eigentlich nur aus der DTAQ und zurück "übersetzt" und sich ansonsten rein in Java bewegt, dann kann man auch das maximale an Komponenten verwenden. Vielleicht sollten wir hierfür mal ein OpenSource Projekt aufmachen...

mfg

Dieter Bender

Die meisten Argumente kann ich nachvollziehen, aber die Empfehlung


ist mir noch nicht untergekommen - maximal das Dauerläuferthreads in Servlets problematisch sein können. Ansonsten habe durchwegs Anregungen und Beispiele für Threads im Webserver gefunden. Und für was gibt es sonst Listener in der web.xml?

Ansonsten kann ich nur sagen, dass ich hier ein paar 24x7-Dienste laufen habe, der längste davon ein halbes Jahr (inkl. Toolboxtreibern für DataQueue, JDBC).

Das mit dem Overhead ist sicher richtig, deshalb verwende ich das (noch) nicht auf der iSeries - bis zum nächsten Hardwaresprung.

Als "halber" Webprogrammierer habe ich meine Dienste freilich schon um Editor für (Properties + xml), Status und Logabfragen erweitert.

Ob nur Dienste für Tomcat den Aufwand rechtfertigen, ist natürlich (wie Dieter Bender schon anmerkte) nicht gesagt.

In meiner Umgebung (Win/Linux/iSeries + fremde + eigene Webanwendungen) war der Umstieg auf Tomcat ein leichtes.

PS. Hier mal mein aktuelles Javaprojekt (Beta), welches ich auch mal herzeigen kann:

http://odtemp.ath.cx/OdKatalog/tree.zul#gr_0
(der AS/400-Teil ist von außen aber nicht erreichbar)

[KM]

Oje, da hab ich ja eine ganz schöne Diskussion angezettelt.

Jetzt hab ich das Ganze halbwegs am Laufen, wird schon wieder davon abgeraten. Ich werde das jetzt aber trotzdem mit dem Tomcat durchführen. Die meisten Probleme habe ich beseitigt. Und die letzten Kleinigkeiten werde ich auch noch finden.

zu 1)Der Hinweis mit dem Thread war genau der richtige. Mein Dienst lief nicht als Thread und hat somit (wie Dieter schon bemerkte) meine Prozedur blockiert. Ich habe das jetzt auf einen Thread umgestellt und siehe da: kaum macht man's richtig, schon funktioniert's. Der Aufruf der Manager-Oberfläche funktioniert jetzt auch wieder bei laufendem Dienst.

zu 2) Ich hatte tatsächlich noch einen "versteckten" System.exit gefunden. Nachdem ich diesen entfernt hatte, ist auch der Tomcat bei Beendigung des Dienstes wie gewünscht weitergelaufen.

zu 3) Ist nach Umstellung auf den Thread auch nicht mehr aufgetreten.

zu 4) Das Problem besteht noch. Da muß ich mir die Anmerkung von Dieter nochmal genauer anschauen. Ich hatte aber im Internet schon mal was über diesen Fehler gefunden. Das werde ich auch noch hinkriegen.

Da das mein erstes Servlet und meine erste Thread-Erzeugung war, hätte ich zu den Threads noch eine Frage. Ist es normal, dass der Thread noch weiterläuft, auch wenn das übergeordnete Servlet beendet wurde ? Mir ist das aufgefallen als ich das Servlet beendet hatte, dass dann die Verarbeitung der DTAQ (die in diesem Thread durchgeführt wird) immer noch stattgefunden hat. Erst durch Beschicken der DTAQ wurde offenbar der Thread beendet. Dann kam auch irgendein "Illegal..." Fehler. Ich werde nun also immer erst den Thread über die DTAQ beenden, bevor ich das Servlet beende.

Die Sache mit dem REXEC gefällt mir hier nicht so. Denn was passiert, wenn der Windows-Server mal neu gestartet wird ? Dann müsste ich den Dienst ja wieder anstarten. Und woher weiß die iSeries das dann ? Außerdem würde doch da für jeden Dienst eine JVM gestartet, oder nicht ?

Ich finde die Sache mit dem Tomcat eigentlich gar nicht so schlecht. Hab dabei echt viel neues gelernt.

Vielen Dank nochmal !

Gruß,
KM

[BenderD]

Hallo,

fangen wir mal mit dem offenen Problem an:

Problem 4: Wenn ich den Listener in das Verzeichnis "classes" stelle und in der web.xml dann nur den Klassennamen (MeinListener) angebe im <listener-class> Tag, dann funktioniert das. Wenn ich aber die Klasse ins Verzeichnis "classes\listener" stelle und in der web.xml die Klasse mit "listener.MeinListener" anspreche, dann erhalte ich einen Fehler beim Starten (...ClassNotFound... wrong name...). Was muß ich ändern, damit das auch funktioniert. Ich wollte eigentlich nicht alle Klassen ins Verzeichnis classes stellen.

listener.MeinListener ist für java eine Klasse MeinListener im package listener und wird im classpath in einem Verzeichnis listener gesucht, du hast, soweit ich das verstehe eine Klasse MeinListener ohne package Angabe im Verzeichnis listener anzubieten, das ist was völlig anderes.
In AS400 Denke formuliert: jede Java Klasse weiß selber in welche Bibliothek sie gehört.

Oje, da hab ich ja eine ganz schöne Diskussion angezettelt.
Jetzt hab ich das Ganze halbwegs am Laufen, wird schon wieder davon abgeraten. Ich werde das jetzt aber trotzdem mit dem Tomcat durchführen. Die meisten Probleme habe ich beseitigt. Und die letzten Kleinigkeiten werde ich auch noch finden.

Das bedeutet nur, dass die Frage Substanz hat. Ich denke dass du mit deiner Lösung so oder so um Längen besser bist, als die meisten RPG Java Verknotungen mit zig aktiven JVMs. Nix ist optimal, man sollte nie aufhören darüber nachzudenken wo noch Verbesserungspotential sitzt.

Da das mein erstes Servlet und meine erste Thread-Erzeugung war, hätte ich zu den Threads noch eine Frage. Ist es normal, dass der Thread noch weiterläuft, auch wenn das übergeordnete Servlet beendet wurde ? Mir ist das aufgefallen als ich das Servlet beendet hatte, dass dann die Verarbeitung der DTAQ (die in diesem Thread durchgeführt wird) immer noch stattgefunden hat. Erst durch Beschicken der DTAQ wurde offenbar der Thread beendet. Dann kam auch irgendein "Illegal..." Fehler. Ich werde nun also immer erst den Thread über die DTAQ beenden, bevor ich das Servlet beende.

Ein Thread ist ein Hundsnormales Objekt in Java und solange ihn jemand kennt (eine Referenz auf ihn besitzt) bleibt er am Leben bis der Sensenmann (, ein Herr namens GarbageCollector) ihn holt, soweit er mit seiner Arbeit fertig ist (sprich sich keine Methode in Ausführung befindet).
Du hast wohl in deiner run Methode (oder von dort aufgerufen) eine Methode, die nicht fertig wird (Schleife mit DataQ horchen, was machen und von vorne). Da kam auch die Sache mit der Pipe her... dein system.exit() kippt die JVM raus und die merkt beim beenden, dass da noch was lief.
Das beenden über DataQ kann man auch aus dem shutdown im Java erledigen, da müsstest du aber etwas genauer sagen, wie du das vorhast.

Die Sache mit dem REXEC gefällt mir hier nicht so. Denn was passiert, wenn der Windows-Server mal neu gestartet wird ? Dann müsste ich den Dienst ja wieder anstarten. Und woher weiß die iSeries das dann ? Außerdem würde doch da für jeden Dienst eine JVM gestartet, oder nicht ?

Ich finde die Sache mit dem Tomcat eigentlich gar nicht so schlecht. Hab dabei echt viel neues gelernt.

Vielen Dank nochmal !

Gruß,
KM

Naja, ich kenne deine AS400 seitige Architektur nicht. Bei meiner Variante gibt es da ein Serviceprogramm, beim ersten Aufruf in der Initialisierung wird ein connect erzeugt (Response DataQ erstellen) da könnte man auch checken ob der Server lebt (indem man ping in die requestQ stellt und der Server mit hallo in der responseQ antwortet) und widrigenfalls starten, ein TimeOut könnte dann auch einen automatischen Wiederanlauf auslösen.

Du bist immer noch bei mehreren Diensten (mit DataQ) bei mir wäre das immer nur einer, der alle Anforderungen kann, warum soll man das duplizieren, (was anderes wäre das nicht). Wenn du denn unbedingt mehrere DataQs abgehorcht haben willst, dann fährst du halt im Start deine 76 Listener hoch, die warten ob jemand was will.

Die Sache mit dem Start beim Restart der Windows Büchse, einen Tod stirbt man ohnehin, wenn der Tomcat abgekackt ist, dann merkt das die AS400 auch nur daran, dass das im wahrsten Sinne des Wortes ewig dauert...

mfg

Dieter Bender

[RobertPic]

Oje, da hab ich ja eine ganz schöne Diskussion angezettelt.

Nicht so schlimm, man sieht nur daran, dass Threads wohlüberlegt eingesetzt werden sollten.

Erzeugung von Threads ist normalerweise dem Container überlassen (der das nebenbei bemerkt. besser kann, der verwendet Pools, kümmert sich um Leichen, etc.)

Thread-Pools (derzeit noch manuell, wenn die letzte 1.4'er AS/400 rausfliegt, dann die von 1.5) verwende ich auch.
Achja, an mein Java lasse ich nur JDBC (Aufrufe von CL/Cobol/RPG nur über Stored Procedures) und maximal DataQueues (und die mit Kontrollthread).

Beispiel: Der Suchindex meiner Katalogapplikation steht via Sockets auch den Cobol/RPG Programmen für die Volltextsuche zur Verfügung. Dazu habe ich einen Listener (Socketserver) mit einem Pool von 5 Threads laufen. Die GreenScreen-Anwendung können so auch Volltextsuchen in den (externen) Katalogdaten (MSSQL-DB) vornehmen.

Da das mein erstes Servlet und meine erste Thread-Erzeugung war, hätte ich zu den Threads noch eine Frage. Ist es normal, dass der Thread noch weiterläuft, auch wenn das übergeordnete Servlet beendet wurde ? Mir ist das aufgefallen als ich das Servlet beendet hatte, dass dann die Verarbeitung der DTAQ (die in diesem Thread durchgeführt wird) immer noch stattgefunden hat. Erst durch Beschicken der DTAQ wurde offenbar der Thread beendet. Dann kam auch irgendein "Illegal..." Fehler. Ich werde nun also immer erst den Thread über die DTAQ beenden, bevor ich das Servlet beende.

Da musst du mir mal erklären wie du das Servlet beendest? Wann der Webcontainer das Servlet wegschmeißt, hängt allein von ihm ab - außer man dreht die Server bzw. die Applikation ab.

[KM]

Hallo,

also das Servlet hatte ich über den Tomcat-Manager beendet. Dabei ist mir eben aufgefallen, dass der Thread noch aktiv war.

Jetzt ist mir aber nochwas unklar. Wenn ich den Thread durch Beschicken der DTAQ z.B. über einen Green-Screen beende, dann wird auch der zugehörigen DTAQ-Server auf der iSeries beendet (QZHQSSRV). Dann kann ich über den Tomcat-Manager das Servlet beenden. Und somit müsste der gesamte Context beendet sein.
Wenn ich nun aber die DTAQ über die destroy()-Methode des Servlets beschicke, dann wird zwar der Thread beendet, aber der DTAQ-Server (QZHQSSRV) bleibt aktiv. Ich hab's auch schon mit as400.disconnectAllServices() versucht. Hat aber nichts gebracht.

Wie kann ich denn nun über das Servlet den Thread sauber beenden, so dass auch die Server auf der iSeries wieder freigegeben werden ? Ich hab's auch mal mit thread.stop() versucht, was man ja eigentlich nicht machen sollte. Aber da wird das Objekt thread nicht gefunden (Cannot resolve symbol), weil es ja in der init()-Methode instanziiert wurde.

Gruß,
KM

[BenderD]

Hallo,

das dürfte eine der Nebenwirkungen sein, weshalb man in einem J2EE Server keine Threads aufmachen sollte, der Container (in diesem Fall Tomcat), kennt den fremden Thread nicht - möglicherweise heilt der garbage Collector das dann später, wenn er (hoffentlich) die DataQ wegschmeißt.
Wenn ich das richtig verstanden habe, dann passt doch bei controlliertem Shutdown (über DataQ) alles?

mfg

Dieter Bender

Hallo,

also das Servlet hatte ich über den Tomcat-Manager beendet. Dabei ist mir eben aufgefallen, dass der Thread noch aktiv war.

Wenn ich nun aber die DTAQ über die destroy()-Methode des Servlets beschicke, dann wird zwar der Thread beendet, aber der DTAQ-Server (QZHQSSRV) bleibt aktiv. Ich hab's auch schon mit as400.disconnectAllServices() versucht. Hat aber nichts gebracht.

Wie kann ich denn nun über das Servlet den Thread sauber beenden, so dass auch die Server auf der iSeries wieder freigegeben werden ? Ich hab's auch mal mit thread.stop() versucht, was man ja eigentlich nicht machen sollte. Aber da wird das Objekt thread nicht gefunden (Cannot resolve symbol), weil es ja in der init()-Methode instanziiert wurde.

Gruß,
KM

[RobertPic]

Wenn ich nun aber die DTAQ über die destroy()-Methode des Servlets beschicke, dann wird zwar der Thread beendet, aber der DTAQ-Server (QZHQSSRV) bleibt aktiv.

Werden da dann beide(!) AS/400-Verbindungen (1x Dienst, 1x dein "Destroyer") geclosed? Teste einmal ob es was bringt, wenn du etwas wartest (ein paar Sekunden sleep).

Ich hab's auch schon mit as400.disconnectAllServices() versucht. Hat aber nichts gebracht.

Wie gesagt, schließt nur die Verbindung für das Objekt as400 - aber du hast da mindestens 2 davon.

Wie kann ich denn nun über das Servlet den Thread sauber beenden, so dass auch die Server auf der iSeries wieder freigegeben werden ? Ich hab's auch mal mit thread.stop() versucht, was man ja eigentlich nicht machen sollte. Aber da wird das Objekt thread nicht gefunden (Cannot resolve symbol), weil es ja in der init()-Methode instanziiert wurde.

Variante 1:
Die Deklaration von Thread wandert noch oben und gilt für die ganze Klasse. Damit erreichst du es dann auch beim destroyed().

Variante 2:
nach dem Starten:

thread.start();      getServletContext().setAttribute("dienst", thread);

und wieder holen mit:

Thread thread = (Thread) getServletContext().getAttribute("dienst");

Ich bin mir allerdings nicht sicher ob thread.stop() dein Problem löst. Sauber wäre wohl thread.interrupt() (ev. mit Zeit) und die InterruptExeception (beim Dataqueue.read im Dienst) abfangen und ein sauberes Ende einleiten.

Eine einfache Lösung ist auch den Thread als daemon zu setzen:

also vor dem thread.start() noch ein:
thread.setDaemon(true);

Damit wird der Thread mit dem Servlet beendet - ich denke das auch hier die InterruptExecption behandelt werden muss.

Nachzulesen im angeführten Link unter Threads in Servlets Abschnitt "Background Threads", Source dazu ist ganz unten.

http://www-i3.informatik.rwth-aachen...em-threads.pdf