Threads vs. JVMs

[Beffe]

Hallo,
für ein neues Softwarepaket wollen wir nicht mehr RPG sondern Java verwenden.
Es werden einige Duzend Prozesse parallel laufen. Im alten RPG-System war jeder Prozess ein separater Job. In Java sind Threads aber komfortabler.

Meine Frage ist, was spricht dafür und was dagegen, alle Prozesse in einer einzelnen JVM und damit einem einzelnen Job laufen zu lassen? Ich habe dazu bisher nicht viel gefunden, außer das jede JVM zusätzlich ca. 100MB Hauptspeicher verbraucht (wäre u.U. nicht das Problem).
Aber wie sieht es mit zusätzlicher CPU-Belastung aus? Gibt es schon Erfahrungen hinsichtlich Offene Datenpfade, Activationgroups, Joblogs etc.?

Vielen Dank im Voraus für jede Antwort.
Gruß,
Beffe

[BenderD]

Hallo,

für Threads spricht:
- deutlich geringerer Overhead
-- jede JVM verbrennt Speicher (die 100 MB sind da eher knapp
-- Caching von Objekten auf allen Ebenen möglich
-- Connection Pools verwendbar
-- einfache Kommunikation zwischen Threads über shared Memory
gegen Threads spricht:
- Synchronisationsprobleme müssen gehandelt werden
- verwendete Funktionen müssen Threadsafe sein (was RPG nicht ist)

Im Java Mainstream verteilt man auf Applikations Server, wenn man mehrere JVMs haben will oder braucht; ansonsten überlässt man sowas den Servern selber.

Dieter Bender,

der meint, dass es wichtigere Architektur Entscheidungen als diese gibt.

Hallo,
für ein neues Softwarepaket wollen wir nicht mehr RPG sondern Java verwenden.
Es werden einige Duzend Prozesse parallel laufen. Im alten RPG-System war jeder Prozess ein separater Job. In Java sind Threads aber komfortabler.

Meine Frage ist, was spricht dafür und was dagegen, alle Prozesse in einer einzelnen JVM und damit einem einzelnen Job laufen zu lassen? Ich habe dazu bisher nicht viel gefunden, außer das jede JVM zusätzlich ca. 100MB Hauptspeicher verbraucht (wäre u.U. nicht das Problem).
Aber wie sieht es mit zusätzlicher CPU-Belastung aus? Gibt es schon Erfahrungen hinsichtlich Offene Datenpfade, Activationgroups, Joblogs etc.?

Vielen Dank im Voraus für jede Antwort.
Gruß,
Beffe

[Beffe]

Danke für die Antwort.
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.

>>der meint, dass es wichtigere Architektur Entscheidungen als diese gibt.<<
Zum Beispiel?

Gruß,
Beffe

[BenderD]

Hallo,

diese Fragestellung hängt mit meiner Antwort zusammen. In einer Java Anwendung ist es üblich ein flexibles logging einzubauen (log4j oder commons.logging), hiermit kann man flexibel (extern konfiguriert) Diagnostics ausgeben, diese Frameworks geben einem die Thread ID mit aus und es gibt Software, die einem die Auswertung der logs vereinfacht - das geht weit über die Möglichkeiten von RPG und ILE hinaus.
Im übrigen ist es meist so, dass man für seine Prozesse einen (fertigen) Server verwendet und der kümmert sich dann automatisch um Threading und solche Dinge.
Joblogs interessieren einen bei einer Java Anwendung im allgemeinen nicht, oder allenfalls, wenn die JVM den Husten kriegt - und dann findet man dort eh nix.

mfg

Dieter Bender

Danke für die Antwort.
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.

>>der meint, dass es wichtigere Architektur Entscheidungen als diese gibt.<<
Zum Beispiel?

Gruß,
Beffe

[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