Grenzen vonTomcat4

[Christoph Zurnieden]

Hallo,

Da Tomcat in Java ist, mindestens in den Grenzen von Java. D.h. das Du mehr PS in der Hardware brauchst, als normalerweise nötig wäre. Angeblich funktioniert auch das garbage colllecting nicht richtig, es ist also deutlich mehr Speicher nötig als normal. Java hat durchaus seine Anwendungsgebiete, aber auf den Server gehört es nun wirklich nicht.
Was denkst Du, _wo_ Java haupsächlich im professionellen Umfeld eingesetzt wird?

Bei Firmen deren Manager sich von SUN haben breitschlagen lassen. >;->

Und meinst Du ernsthaft, das die Frage, ob 1 oder 2 Prozessoren oder 1 oder 2 GByte RAM in die Maschine sollen, dabei eine Rolle spielt?

Die eben angegebenen 365.000 EUR hören sich viel an, aber für Hard- _und_ Software ist wirklich nicht mehr viel. Da kann es durchaus sein, das die Ausstattung der Hardware eine Rolle spielt. Z.B. wenn der Chef unbedingt als Datenbank eine Produkt der Firma Oracle haben möchte ;-)

Dynamisches (ent)laden funktioniert bei Java nicht richtig.
Meinst Du die Java-Spezifikation oder bestimmte J2SE Versionen?

Ich habe einige Versuche gesehen auf den verschiedensten Java-VMs, richtig funktioniert hat das nie.
Die letzte Spezifikation kenne ich aber nicht genau genug. Vielleicht ist es ja zumindest geplant.

Das ist typisch Java, das liegt nicht an Tomcat. Eine Art "renice" für die Javathreads gibt es IMHO nicht. Es kann auch durchaus sein, das soviel Speicher bei der Aktion verbraten wird, das die Maschine anfängt zu swappen. Der JAVA-GC ist bei so einer Einzelaktion nicht in der Lage Speicher freizugeben, so man es ihm nicht explizit sagt.
Christoph, Du bemühst sehr viele (überholte) Klischees, um ein Performanzproblem zu erklären, deren Natur Du nicht kennst

Hey, darunter stand eigentlich noch ein Hinweis, das es doch evt die DB sein müßte! ;-)

Aber wo wir gerade beim Thema sind:
Ich hatte erst letzthin eine Diskussion, ob sich der Port einer Software nach Java hin lohne, empfehle oder doch eher zu lassen sei.
Dabei kamen folgende Punkte auf's Tapet:

• Java ist eine proprietäre Sprache, eine Weiterentwicklung/Bugfix ist nicht gesichert (Das war übrigens dann das KO Argument)

• die Portabilität von Javaprogrammen ist eine Mär (nicht vollständig bewiesen, aber es gab eine ganze Reihe an Beispielen, die auf einer JVM liefen und auf einer anderen wiederum nicht. Woran das genau lag konnte und/oder wollte keiner nachvollziehen)

• es handelt sich im Grunde genommen um eine interpretierte Sprache (Auch wenn es Bytecode ist) mit allen ihren natürlichen Vor- und Nachteilen.

• sicherheitstechnisch nicht unbedenklich

• es gibt mittlerweile viele Kleingeräte (Handhelds, Mobiltelephone etc) die über eine JavaVM verfügen. (Deswegen sind wir überhaupt auf Java gekommen)

• ein einfaches Programm läßt sich in Java recht schnell realisieren

• kompliziertere Programme erfordern einen unverhältnismäßig hohen Aufwand

• die Lernkurve ist am Anfang recht steil

• die Lernkurve ist gegen Ende hin fast parallel

Da die Diskussion trotz des KO Argumentes (es gibt ja immerhin noch die Bestrebungen von "Kaffe" und die JVM in den Kleingeräten ist wirklich sehr reizvoll) nicht ganz am Ende ist, wäre mir an Deinen evt Gegenargumenten sehr gelegen.

so short

Christoph Zurnieden