Da gerade der Tomcat wieder etwas zickig ist, hab ich nochmal genauer geguckt was in den einzelnen Ordner so rumliegt.
Im temp-Verzeichnis sind verschiedene Ordner zu meinen Applikationen, soweit alles okay. Jetzt hab ich mal in die alten reingeschaut und gesehen, das oft nur noch eine *.jar drin liegt. Warum kann der Tomcat diese nicht selbstständig löschen? Oder sind die von einem missglücktem undeploy über geblieben?
Erkläre doch mal das Problem mit dem Tomcat bevor wir uns über temp Dateien unterhalten müssen.
Was meinst du mit zickig?
… was ist das für eine Jar, kennst du die? Eine von dir? Wie deployst du? Welches Betriebssystem liegt unter dem Tomcat?
Der Tomcat 7.0.42 lauft auf einem Windows Server 2008 R2, dieser Server ist aber nur ein virtueller irgendwo im Firmennetz. JVM-Version 1.6.0_45-b06 von Sun.
Zickig bedeutet das er gestern ständig wegen java.lang.OutOfMemoryError: PermGen space gemeckert hat. Er läuft aber mit der gleichen Version und bei der Anwendung hab ich nichts signifikantes geändert. Vorher lief er ohne Probleme. Um dem Speicher-Problem vorzubeugen hab ich erst immer die alte Anwendung undeployt, dann Tomcat gestoppt und wieder gestartet und im Anschluss die neue version deployt.
Die Anwendung wird aus Netbeans herraus mit rechtsklick -->Clean & Build als *.war gepackt und dann mit dem WebManager von Tomcat auf dem Server deployt.
Die jar ist von primefaces3.5, welches ich in meiner Anwendung benutze.
Jetzt hab gerade nochmal ins Log geschaut und festgestellt, das Hibernate auch ein Problem hat.
20.02.2014 09:46:39 org.hibernate.engine.loading.LoadContexts cleanup
WARNUNG: fail-safe cleanup (collections) : org.hibernate.engine.loading.CollectionLoadContext@46bc720e<rs=oracle.jdbc.driver.OracleResultSetImpl@526355af>
Dieser Fehler ist aber erst aufgetaucht, nachdem der Server wieder stabil lief.
Na also, dachte ichs mir doch.
Das hat rein gar nix mit dem Temp Dateien zu tun.
Das heisst lediglich, das der PermGernSpace zu klein ist.
Mit welchen Heap und PermGen Space Einstellungen faehrst du den TC denn?
Wenn du da nix zu weisst, also nur die Defaulteinstellungen nimmst, ist das vollkommen normal.
Dann legst du einfach eine Datei namens „setenv.bat“ (fuer Tomcat unter Windows) im bin Verzeichins an, und weisst darin mehr Speicher zu, in etwa:
set JAVA_OPTS= -XX:PermSize=128m -Xmx512m
Damit waeren 128MiB fuer den PermGen und 512MiB fuer den Heap zugewiesen, musst jhalt sehen was deine Anwendung so braucht.
eigentlich ahtte ich dem schon mal mehr Speicher zugewisen, in meiner setenv.bat steht folgendes:
set CATALINA_OPTS=-Dcom.sun.management.jmxremote=true
set JAVA_OPTS="-XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled"
Den Heap speicher hab ich nicht geändert, könnt darin das Problem liegen, das er die Werte für den PermGen-Speicher ignoriert?
Sieh dir doch mal mit VirtualVM an was da so los ist.
Wie lange läuft denn der TC ohne neustart und wie oft redeployst du die WebApp?
Du meinst sicherlich VisualVM.
[QUOTE=maki]Sieh dir doch mal mit VirtualVM an was da so los ist.
Wie lange läuft denn der TC ohne neustart und wie oft redeployst du die WebApp?[/QUOTE]
Ich kann mich auch den Server nur Remote anmelde, kann also nicht mit Tools den Speicher angucken. Im Taskmanager seh ich aber das der Prozess der Tomcat7.exe ca. 230MB RAM nutzt.
Wenn ich nach einem Neustart die Anwendung deploye läuft er ohne Probleme. Zur Zeit muß ich ca. 2mal die Woche aber neu deployen. Ohne neustart des Tomcat nach dem undeploy geht es dabei aber nie.
Siehe hier:
https://tomcat.apache.org/tomcat-7.0-doc/monitoring.html
Mit VisualVM kannst du dich dann via JMX mit dem Tomcat verbinden.
Ich hatte ja eine zeitlang psi-probe drauf, da lief der Tomcat mit der Anwendung bei rund 80MB PermGen, das zeigt mir aber auch der html-Manager vom Tomcat an. Hab die psi-probe dann wieder runter gehauen, weil der Tomcat ja stabil lief.
Das mit VisualVM werd ich mir mal genauer angucken.