Java-Applikation als Server-Dienst

[KM]

Danke für die Links. Ich werde das mal ausprobieren.

Wenn Du aber auch einen Hinweis für mich hast, wie ich das unter Tomcat laufen lassen kann (ohne eine EXE zu erstellen), wäre ich Dir auch sehr dankbar. Wenn das ohne EXE ginge, wäre es mir sogar lieber als die Variante mit dem Windows-Dienst.

Gruß,
KM

[BenderD]

Hallo,

also exe braucht man da so oder so keine, man kann die java.exe als Service eintragen und der als Parameter deine Java Klasse mit main mitgeben; Anleitung in dem vorher angegebenen Link. Wenn dieser Service Autostart ist, dann fährt das automatisch hoch mit Windows.

Unter Tomcat geht das auch, dann installiert man den Tomcat als automatisch zu startenden Dienst, legt da eine Web Applikation an, oder missbraucht eine vorhandene kleine Demoanwendung dazu. In der web.xml dieser Anwendung kann man Servlets eintragen, die beim Start des Containers geladen werden; der Eintrag sieht dann so aus:

<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>com.kcole.mypackage.MyServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

In solch einem Servlet überschreibt man die init Methode und startet dort seinen eigenen Dienst (nicht die main aufrufen, sondern mit new MyService().run() , wobei die run Methode jetzt das enthält, was aus der main gestartet wird.

mfg

Dieter Bender

Danke für die Links. Ich werde das mal ausprobieren.

Wenn Du aber auch einen Hinweis für mich hast, wie ich das unter Tomcat laufen lassen kann (ohne eine EXE zu erstellen), wäre ich Dir auch sehr dankbar. Wenn das ohne EXE ginge, wäre es mir sogar lieber als die Variante mit dem Windows-Dienst.

Gruß,
KM

[RobertPic]

Wenn Du aber auch einen Hinweis für mich hast, wie ich das unter Tomcat laufen lassen kann (ohne eine EXE zu erstellen), wäre ich Dir auch sehr dankbar. Wenn das ohne EXE ginge, wäre es mir sogar lieber als die Variante mit dem Windows-Dienst.

Ich noch meine Erfahrungen zu den einzelnen Varianten - auch ich bevorzuge die Tomcat-Variante.


zum GCJ:

• habe ich getestet und stufe das als Projekt im Betastadium ein. Vor allem wenn man viele fremde JAR's einbindet kann es mühsam werden.
• Weiters benötigt man eine Linuxumgebung unter Windows (z.B. cygwin oder miniGW) damit gcj auch funktioniert. Bei cygwin muss man dann noch ein DLL mitgeben.
• Selbst wenn man ein Exe hinbekommt, ist es nicht sicher, dass die Sache auch funkioniert.
• Schneller ist nur das Startverhalten, der Rest ist langsamer als normales Java.
• Das exe braucht zur Laufzeit aber weniger Hauptspeicher, als eine JVM.

--> zuviel "gefrickel"

zu den Exe-Wrappern:

• Von den exe-Wrappern verwende ich auch JSmooth.
• Vorteile:
• eigenes Programmsymbol
• eigener Programmname in Taskmanager (nicht javaw)
• kein Zip-Programm welche sich auf einmal die jar-Endung schnappt un den Start verhindert
• --> verwende ich allerdings nur für kleine GUI Programme, nicht für Dienste
  
  zu den Java Service Wrappern:
• Hier habe ich den Open Source "Java Service Wrapper" getestet. http://sourceforge.net/projects/wrapper/
• Hat prinzipiell funktioniert, aber die Vorteile von Tomcat (Stichwort: Wartung über Web) zogen doch "besser"

zum Tomcat:

• Ich verwende hier Tomcat 5.5, mit der JRE 1.5

Vorteile:

• Statusabfrage, Start/Stop - alles über Web (Standardport 8080) machbar
• Auch das Deployen ist über Web machbar (war-Datei über den Manager der Weboberfläche hochladen und installieren)
• kein extra Aufwand für das Verpacken (wie bei JSmooth oder den Service Wrapper) - einfach in Eclipse ein war-File exportieren
• in meiner Firmenumgebung: Javadienste im Tomcat sind überall (Windows, Linux) gleich zu starten bzw. zu beenden
• Mit Webprogrammierung auch Log und Konfiguration der Applikation über Web möglich.

Kleiner Crashkurs für Tomcat/Web

Zur Installation:
Ab der Version 5.5 bringt Tomcat einen eigenen Compiler mit. Damit reicht eine Java Runtime (ab JRE 1.5) aus. Das Installfile vom Tomcat hat gerade mal 5.5 MB und ist auch schnell installiert. Im Setupprogramm kann man dann auch sagen, ob Tomcat als Dienst laufen soll.

Wenn der Tomcat gestartet ist, geht es über die Weboberfläche weiter:

http://localhost:8080/ oder die http://ip-adresse:8080/ von einem anderen PC

Dort klickt man auf den Manager, und man muss ein Passwort eingeben (Standard ist glaube ich manager/manager oder tomcat/tomcat).

Installation der Applikation:
Unter:
Lokale WAR Datei zur Installation hochladen

auf dursuchen und das lokale war-File auf den Server uploaden und anschließend mit "Installieren" beenden --> das war es in vielen Fällen schon.

War-File mit Eclipse (inkl. WST) erzeugen
Wenn man neues Webprojekt erzeugt, wird automatisch die ganze Struktur angelegt. Die Javasourcen liegen wie gewohnt unter src.

Im Verzeichnis Web-Content/WEB-INF liegt die Datei web.xml. Dort muss jetzt dein Startprogramm eingetragen werden. Entweder so, wie es von Dieter beschrieben wurde, oder auch als Listener - was ich persönlich bevorzuge, da man hier auch das Ende mitbekommt:

in die web.xml einfügen:

<listener>
           <listener-class>com.at.od.web.ehkat.DbStarter</listener-class>
    </listener>

Die Klasse schaut dann so aus:

public class DbStarter implements ServletContextListener {
   
    public void contextInitialized(ServletContextEvent servletContextEvent) {
    // Hier den Dienst als Thread starten
    }

public void contextDestroyed(ServletContextEvent servletContextEvent) {
   // Hier den Thread wieder beenden
    }
}

Für zusätzlich benötige fremde Jar-Bibliotheken gibt es 2 Möglichkeiten:
1.) Die Jar-Dateien in die Bibliothek WEB-INF/lib kopieren (die Dateien aus dem Explorer in das Verzeichnis WEB-INB/lib in der Eclipse-Umgebung kopieren.

2.) Häufig gemeinsame Bibliotheken kann man auch im tomcat unter:
...Tomcat 5.5\shared\lib ablegen. Damit stehen diese jars allen Applikationen zur Verfügung.

Beim Export gibt es unter "Web" die Auswahl War-File. Das damit erstellte war-File kann man dann wie oben beschrieben auf den Tomcatserver deployen.

Start/Stop/Entfernen und neu Installieren läuft alles über die Weboberfläche des Managers.

[KM]

Vielen Dank für die ausführlichen Antworten !

Ich habe inzwischen den Tomcat 5.5 und die JRE 1.5 installiert. Der Tomcat-Server läuft auch ohne Probleme. Jetzt hapert's nur noch am Servlet. Da es mein erstes Servlet wird, ist mir noch nicht so ganz klar wo ich was machen muß. Habe ich das nun richtig verstanden, dass die service()-Methode nicht benötigt wird und ich meinen ganzen Programmcode in die init() schreiben muß ? Oder was ist mit "new MyService().run()" gemeint ?

Gruß,
KM

[BenderD]

Hallo,

du kannst entweder die Variante von Robert nehmen, dann schreibst du halt einen ServletContextListener und überschreibts dort die contextInitialized. Oder du schreibst eine Klasse
class MyClass extends HttpServlet
und überschreibst dort die init.
In diesem oder jenem Fall packst du dann die Logik, die jetzt in deiner main Methode steht darein.

mfg

Dieter Bender

Vielen Dank für die ausführlichen Antworten !

Ich habe inzwischen den Tomcat 5.5 und die JRE 1.5 installiert. Der Tomcat-Server läuft auch ohne Probleme. Jetzt hapert's nur noch am Servlet. Da es mein erstes Servlet wird, ist mir noch nicht so ganz klar wo ich was machen muß. Habe ich das nun richtig verstanden, dass die service()-Methode nicht benötigt wird und ich meinen ganzen Programmcode in die init() schreiben muß ? Oder was ist mit "new MyService().run()" gemeint ?

Gruß,
KM

[KM]

...mühsam ernährt sich das Eichhörnchen...

Jetzt hab ich beide Varianten mal ausprobiert und habe noch folgende Fragen/Probleme:

Ich bekomme sowohl die Servlet- als auch die Listener-Variante zum Laufen und sie funktionieren sogar. Das ist schon mal das Positive.

Problem 1: Wenn einer dieser Dienste allerdings läuft, komme ich nicht mehr auf die Manager-Oberfläche (http://localhost:8080). Der Browser bleibt ewig hängen. Sobald der Dienst beendet ist, komme ich wieder drauf. Woran kann das liegen ?

Problem 2: Wie bereits erwähnt, lauscht dieser Dienst auf einer DTAQ. Wenn ich diese DTAQ so beschicke, dass der Dienst beendet wird, wird automatisch auch der komplette Tomcat-Server beendet. Ist das normal ?

Problem 3: Wenn ich den Tomcat-Server beende, solange der Dienst noch aktiv ist, erhalte ich "Systemfehler 109. Die Pipe wurde beendet". Ich vermute mal das liegt daran, dass der DTAQ-Job unsauber beendet wird, oder ?

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.

Problem 5: Gibt es eine Möglichkeit Dienste auch anders zu starten/beenden als über die Manager-Oberfläche ?

Vielen Dank schon mal im Voraus.

KM

[RobertPic]

zu Problem Nr. 1:
In meiner Antwort steht, dass du das als Thread starten musst - schaut aber nicht so aus....

Wenn du deine Klasse nicht verändern willst, kannst du eine anonyme Klasse machen:

 Thread thread = new Thread ()  {
      public void run () {
         System.out.println("Start...");
         // hier deine Klasse starten
      }   
   };
   thread.start();

zu Problem Nr. 2+3:
Möglicherweise löst der Thread auch gleich das Problem - oder machst du eine system.exit?

Problem Nr. 3:
Beim Listener kannst du in contextDestroyed den Dienst sauber beenden:

Variante 1:
thread.interrupt(); im Dienst die Exception verarbeiten, sprich alles zumachen. Im Listener/contextDestroyed das Ende des Threads abwarten thread.join oder thread.join(x); wobei x die Zeit ist, wie lange man wartet.

Variante 2:
Du übergibst an den Thread eine Objektreferenz, über welche du dann mit dem Dienst kommunzierst und z.B. eine Ende anfordern kannst.

Problem Nr. 4
Sollte so eigentlich funktionieren???

Problem Nr. 5
1. Man kann den Tomcat als Dienst beenden oder über das Wartungstool. Das würde auch deinen Dienst beenden.
2. Man kann ein Servlet/JSP machen. Also einfach einen Webeinstieg ohne Manager sondern über eigene HTML Seiten.
3. Jede andere Möglichkeit, wie sie auch bei einem normalen Javaprogramm vorkommt (also Flags über DataQueue, Socket, Datei......)

[BenderD]

Hallo,

ad 1: wenn dein NEP (never ending program) Dienst nicht in einem eigenen Thread gestartet wird, blockiert er die Initialisierung.

ad 2: falls du einen system.exit() machst, beendest du die komplette JVM und damit den Tomcat. Zum beenden brauchst du eigentlich nur deine eigene Schleife zu verlassen, dann terminiert das ganze automatisch.

ad 3: das wird wohl so sein.

ad 4: das Verzeichnis classes wird nicht direkt exportiert und ist die root des classpath der Anwendung. Offenkundig befindet sich deine Klasse im namenlosen package (keine package Angabe), es sollte allerdings wg. Namenskonflikten ein Package angegeben werden, dass mit deiner umgekehrten WebAdresse anfängt, sinnigerweise dann die Applikation beinhaltet; z.B.: package de.bender_dv.javagate) dann muss die Klasse in classes/de/bender_dv/javagate platziert werden, bei der Verwendung brauchst du dann einen import, bzw musst die Klasse qualifiziert adressieren.

ad 5: halt zusätzlich über einen Servlet Einstieg, aber dann wieder als Thread.

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

Ich würde da eher zum Start per REXEC Aufruf tendieren, reguläres Ende per DTAQ ansteuern, das geht auch transparent auf allen Büchsen gleich. (Über Beendigung eines festgefressenen müsste ich nochmal nachdenken.

Der ursprünglich gedachte Windows Dienst liegt da für mich in der Mitte.

mfg

Dieter Bender

...mühsam ernährt sich das Eichhörnchen...

Jetzt hab ich beide Varianten mal ausprobiert und habe noch folgende Fragen/Probleme:

Ich bekomme sowohl die Servlet- als auch die Listener-Variante zum Laufen und sie funktionieren sogar. Das ist schon mal das Positive.

Problem 1: Wenn einer dieser Dienste allerdings läuft, komme ich nicht mehr auf die Manager-Oberfläche (http://localhost:8080). Der Browser bleibt ewig hängen. Sobald der Dienst beendet ist, komme ich wieder drauf. Woran kann das liegen ?

Problem 2: Wie bereits erwähnt, lauscht dieser Dienst auf einer DTAQ. Wenn ich diese DTAQ so beschicke, dass der Dienst beendet wird, wird automatisch auch der komplette Tomcat-Server beendet. Ist das normal ?

Problem 3: Wenn ich den Tomcat-Server beende, solange der Dienst noch aktiv ist, erhalte ich "Systemfehler 109. Die Pipe wurde beendet". Ich vermute mal das liegt daran, dass der DTAQ-Job unsauber beendet wird, oder ?

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.

Problem 5: Gibt es eine Möglichkeit Dienste auch anders zu starten/beenden als über die Manager-Oberfläche ?

Vielen Dank schon mal im Voraus.

KM

[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