Threads vs. JVMs

[RobertPic]

Ich kann (fast) nur postive Erfahrungen mit Threads statt eigenen JVM's berichten. Ich habe da keine Nachteile in Sachen CPU-Belastung feststellen können - der RAM-Verbrauch ist sowieso besser.

Bei Anwendungen, welche von "Haus aus" parallel arbeiten müssen, sind eigene JVM's sowieso keine Alternativen:

Beispiel:
Ich habe einen TCP-Socket-Listener, welcher Anfragen aus einer Web-Applikation abarbeitet. Da es dort kurze (Lagerstand, Preis) und lange (Fakturen, Lieferscheine aus dem Archiv) Abfragen gibt, kann ich das nicht einfach sequentiell abarbeiten, daher habe ich parallel 5 Threads laufen, auf welche die Arbeit aufgeteilt wird.
Soetwas auseinanderzureißen macht wenig Sinn.

Ich habe aber auch "fremde" Threads (z.B. FTP-Listener, LDAP-Sync, PDF-Wandlung) in eine JVM zusammengelegt - prinzipiell kein Problem.

ABER:
- Wie von Dieter Bender schon angesprochen, müssen die Klassen Thread-save sein. Das betrifft vor allem die gemeinsam benutzten Klassen (Util's, Standardmodule...). Hier hat sich das eine oder andere static aus Anfängerzeiten bemerkbar gemacht...

Ist aber alles halb so wild, falls du das genauer wissen willst, nochmal nachfragen.

- wenn irgendwo ein Programm ein system.exit macht, ist die ganze JVM weg.

- Wenn ich verschiedene Programme in einer JVM laufen habe, kann diese nicht einzeln beenden (außer ich baue mir irgendeine Steuerung dazu) sondern nur alle.

Im Moment verfahre ich so, dass ich neuen Projekten eine eigene JVM spendiere und erst später (wenn das gröbste Überstanden ist) in der allgemeinen JVM einbinde.

Wenn nächstes Jahr die neue i5-Hardware anrollt, werde ich wahrscheinlich auf Web-Container (war) umsteigen. Hier kann ich im Tomcat oder WAS jede Applikation für sich beenden und neu starten. Die Programme werden dann als "Listener" deklariert. Die Weboberfläche verwende ich nur zur Statusanzeige und zum Konfigurieren der (Batch)Anwendung.

Robert

[RobertPic]

Die Frage ob Jobs oder Threads stellt sich bei uns vor allem auf Grund der Befürchtung mit Threads auf Analysemöglichkeiten verzichten zu müssen. Wenn alle Prozesse in einem Job laufen wird es vielleicht sehr schwer oder gar unmöglich ein aufgetretenes Problem zuzuordnen.

Auch hierzu noch ein Kommentar:
Wie Dieter Bender schon sagte, ist die Analyse dank Log-Modulen kein Problem. Weiters laufen meine erste Gehversuche (auch produktiv) sowie innerhalb von Eclipse - und da kann ich sogar debuggen.

Eine eigene JVM hat allerdings den Vorteil, dass man den Resourcenverbrauch (CPU, temporärer Speicher) auf der AS/400 etwas besser abschätzen kann. Aber wie gesagt: Das mache ich die ersten paar Tage und dann ab in die gemeinsame JVM. Derzeit muss ich noch etwas Rücksicht auf die alten AS/400 nehmen....

Überwachungstools gibt es allerdings auch für Tomcat - bisher habe ich mich damit noch nicht auseinandergesetzt.

Robert

[BenderD]

Hallo,

das war so eine der wichtigen Architekturentscheidungen, die man an den Anfang gelegt hätte, wenn man das Ganze aus der Java Perspektive betrachtet hätte. Mit dieser Maßnahme gewinnt man sofort Verteilungstransparenz (sprich: man kann das Ganze auch auf einer anderen Büchse laufen lassen), was die Skalierbarkeit massiv erhöht und Hardwarekosten drastisch senken kann.
Java auf der AS400 krankt in erster Linie daran, dass viele unnötige Sonderlocken gedreht werden. Wer abschreckende Beispiele sucht, der bemühe mal Herrn Google mit java400-l

mfg

Dieter Bender

Wenn nächstes Jahr die neue i5-Hardware anrollt, werde ich wahrscheinlich auf Web-Container (war) umsteigen. Hier kann ich im Tomcat oder WAS jede Applikation für sich beenden und neu starten. Die Programme werden dann als "Listener" deklariert. Die Weboberfläche verwende ich nur zur Statusanzeige und zum Konfigurieren der (Batch)Anwendung.

Robert