Ich habe einen Tomcat 6 Server auf einem Ubuntu 12.04 Server mit 4GB und den folgenden JAVA_OPTS
JAVA_OPTS="-Djava.awt.headless=true -Xms512M -Xmx512M -XX:PermSize=1024M -XX:MaxPermSize=1024M -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled"
Dumme Frage: Wenn ich dieselbe Webanwendung (dieselbe War-Datei) mehrmals bereitstelle (jedes Mal verweist es auf eine andere Postgres-Datenbank) – als server.com:8080/webapp1, server.com:8080/webapp2 usw. …
darf ich davon ausgehen, dass Tomcat die Klassendateien einmalig für alle Webanwendungen zwischenspeichert? Oder speichert Tomcat die Klassen pro Webanwendung zwischen?
Vielen Dank im Voraus Danny
Antwort1
Die Antwort hängt davon ab, wo Sie die von Ihrer Webanwendung verwendeten Klassendateien gefunden haben.
Wenn Sie eine bestimmte Klasse in den Tomcat Common Class Loader-Pfad von $CATALINA_HOME/lib einfügen, wird sie allen Webanwendungen zur Verfügung gestellt. Dasselbe gilt für die zwischengespeicherte Form.
Wenn Sie den Tomcat-Webanwendungsklassenladerpfad webapps/ verwendenWeb-App/WEB-INF/Klassen und Webanwendungen/Web-App/WEB-INF/lib: Die Klassen und entsprechenden Klassen-Caches sind zwischen Anwendungen isoliert.
Technischer Hintergrund
Tomcat entspricht nicht der Art und Weise, wie Java Klassen nativ verarbeitet, sondern verwendet einen benutzerdefinierten Java-Klassenlader. Dadurch werden eine Reihe von Funktionen erzwungen, die sich auf Folgendes beziehen:
- Klassenverarbeitung innerhalb einer Webanwendung
- Klassen-Caching pro Webanwendung
- Vorladen und Neuladen von Klassen beim Start/zur Laufzeit der Webanwendung
- Sicherheit beim Laden/Referenzieren von Klassen
Der benutzerdefinierte Tomcat-Klassenlader verwendet die Java-Standardklassenlader Bootstrap, Extension und System, ersetzt jedoch die vom Systemklassenlader verwendete Klassenpfadvariable durch seinen eigenen Klassenpfad. Dies hat folgende Auswirkungen:
- Ersetzen des mit Java gelieferten Endorsed Standards Override Mechanism durch den eigenen von Tomcat.
Hinzufügen von zwei zusätzlichen Klassenladern am Ende der Java-Klassenladehierarchie:
- Der Tomcat Common-Klassenlader
- Ein separater Klassenlader pro Webanwendung
Der ursprüngliche Klassenpfad wird von Tomcat ignoriert.
Ein wichtiges Detail ist, dass ein Webapp-Klassenlader das Laden von Klassen nicht zuerst an seine übergeordneten Klassen delegiert, sondern versucht, jede Klasse bei Anforderung zu laden. Jede geladene Klasse wird anschließend vom betreffenden Webapp-Klassenlader zwischengespeichert. Diese Klassenlader-/Cache-Ebene kann nicht zwischen Webapps geteilt werden.
Alle vom Common Class Loader geladenen Klassen werden allen Webanwendungen öffentlich zur Verfügung gestellt, einschließlich des Caches. Von einer umfangreichen Platzierung von Klassen im Common Class Loader-Pfad wird abgeraten, da dies:
- unterbricht die Portabilität
- Die Anforderungen an die Klassenversion können zwischen Tomcat und verschiedenen Webanwendungen unterschiedlich sein.
- Wartung wird zum Problem: Welche Klasse gehörte wohin?
Es gibt eine Menge Kleingedrucktes zum Laden/Caching/Neuladen von Klassen. Wenn das wichtig ist, würde ich vorschlagen, das hervorragende Kapitel zum Laden von Klassen imProfessioneller Apache Tomcat 6.
Eine komprimierte Version wurde von jemandem geschrieben aufDasSeite.