Tomcat 6 Speicherverluste log-Einträge

Unten ist outtake der eindeutigen Einträge in meiner Catalina.aus Datei auf CentOS Maschine. Ich bin mit Tomcat 6 mit spring 3 und meine Anwendung. Es gibt ein ganzes Bündel von Ihnen, so nahm ich einfach einige die sich immer wiederholen. Dies passiert nicht die ganze Zeit aber es passiert mindestens einmal in der Woche.

Die Frage ist, was kann ich tun, um zu verhindern, dass der Balg passiert?

Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc

SEVERE: The web application [] registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.

Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

SEVERE: The web application [] appears to have started a thread named [com.iteezy.shared.domain.DirEntry.data] but has failed to stop it. This is very likely to create a memory leak.


Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named

[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] but has failed to stop it. This is very likely to create a memory leak.


Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads  

SEVERE: The web application [] appears to have started a thread named [File Reaper] but has failed to stop it. This is very likely to create a memory leak.

Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

SEVERE: The web application [] appears to have started a thread named [pool-1-thread-22] but has failed to stop it. This is very likely to create a memory leak.  

37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
b application [] appears to have started a thread named 

[org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-2] but has failed to stop it. This is very likely to create a memory leak.

37:48 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap

b application [] created a ThreadLocal with key of type [net.sf.json.AbstractJSON$1] (value [net.sf.json.AbstractJSON$1@40bbb3d6]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

InformationsquelleAutor Mat B. | 2011-02-04

12

Beim definieren einer externen fahne, die ein thread ist wohl an genick-und Ausgang, wenn er gesetzt ist - es muss volatile. Ansonsten ist der thread vielleicht nie sehen die änderung durch anderen thread.

Allerdings gibt es bereits eine Funktion, so dass in der standard-API - es heißt ein interrupt() Methode und Thread.currentThread().isInterrupted(). Keine Notwendigkeit zu duplizieren bereits vorhandener Logik. Siehe: Stoppen einer bestimmten java-thread.

That being said calling interrupt() auf jeder thread ist eine schlechte Idee als gut, weil es gibt keine Garantie, dass alle threads zu beantworten. Untersuchen Sie Ihre Ausnahmen bemerkte ich die folgenden threads, die nicht ordnungsgemäß bereinigt:
- com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0 - schließen Sie die C3P0 Datenquelle. Da man sich mit Feder fügen Sie einfach destroy-method="close". Wir sind fertig mit diesem thread.
- File Reaper - so weit ich das sehen kann ist dieser thread wird erstellt, indem FileCleaningTracker. Müssen Sie rufen Sie FileCleaningTracker.exitWhenFinished() explizit beim Herunterfahren der Applikation (oder, wenn die Klasse nicht mehr benötigt, ich habe es nie benutzt), oder lass den Frühling, dies zu tun (siehe oben). Die Chancen sind einige 3rd-party-Bibliothek verwendet und es nicht richtig schließen - das heißt, es hat einen bug.
- pool-1-thread-22 - dies ist einer der threads, die erstellt von Vollstrecker utility innen ExecutorService. Stellen Sie sicher, Sie rufen shutdown() auf jeder solchen pool in Ihrer Anwendung beim Herunterfahren.
- org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-2 - Quarz-worker-thread (der eigentlich läuft der Arbeitsplätze). SchedulerFactoryBean schließt der scheduler automatisch für Sie, ich denke, Tomcat ist hier falsch, ich sehe diese Fehler oft als gut. Dennoch sieht die Einstellung SchedulerFactoryBean.waitForJobsToCompleteOnShutdown zu true löst dieses.
- com.iteezy.shared.domain.DirEntry.data - Ich bin mir nicht sicher über diese ein. Es ist entweder Ihr eigener thread, muss unterbrochen werden beim Herunterfahren oder H2-Datenbank-thread (?) Ihr stack muss untersucht werden, um zu erraten, Woher es kommt.
Die Quintessenz ist: nicht nur töten alles was sich bewegt (eigentlich Tomcat hat für Sie nach Erteilung dieser Warnung), aber bestimmen, wo die Fäden herkommen und Gebrauch framework/Bibliothek bestimmten close() Methode um eine weitere Säuberungsaktion. Sanft sein.

InformationsquelleAutor Tomasz Nurkiewicz
1

Eingerichtet, ein Servlet zu verwalten, diese in seiner destroy() Methode. Das Gewinde kann mit einer Flagge zu sehen, ob Sie müssen oder nicht fortgesetzt werden.

In Ihrem servlet, tun Sie Folgendes in der destroy-Methode. Sie müssen natürlich in der Lage sein, um Zugang zu einem Collection<MyThread> aber wie bekommst du das hängt wirklich davon ab, wie Ihr system eingerichtet ist.
```
destroy() {
    for (MyThread thread : myThreads) {
        thread.stopProcessing();
    }
}
```
Ihre MyThread Klasse haben so etwas wie dieses:
```
public class MyThread {
    private boolean finished = false;

    @Override
    public void run() {
        while (!finished) {
            //do something
        }
    }

    public void stopProcessing() {
        finished = true;
    }
}
```
- Ich habe aktualisiert mit einem basic-Skelett ein Beispiel
- Muss ich überschreiben Sie die destroy-Methode auf jedem servlet auf meinem system? Auch setze ich die Klasse MyThread unter jedem servlet?
- Nein, nur überschreiben müssen zerstören, die auf einem servlet ein servlet ist, das ist nicht wirklich überall aufgerufen, aber eingeleitet (web.xml). Dann das servlet braucht Zugriff auf eine Sammlung von threads, und es durchläuft, dass die Sammlung in der destroy-Methode. Sie müssen natürlich zum füllen der collection, wenn die threads erstellt werden, und Sie müssen sicherstellen, dass threads, die abgeschlossen sein, bevor der Tomcat heruntergefahren entfernen Sie sich aus der Kollektion, die ansonsten bekommen Sie memory leaks!
- finished werden volatile auch, warum nicht einfach bestehende interrupted fahne verfügbar für jeden thread? Siehe: stackoverflow.com/questions/7786305
InformationsquelleAutor Rich
-1

Shutdown webapp richtig. Don ' T lassen diese threads laufen.

Alternativ, nicht immer, durch eine Neuausrichtung der webapp.
- Dies ist sehr hilfreich, Beratung, ähnlich wie "just say no". Die OP wurde heruntergefahren die webapp richtig zu seinem Verstand, als ein feature von Tomcat (und fast alle anderen servlet-container) ist zu stoppen webapps ohne Besondere Codierung erforderlich. Tomascz Kommentar nicht nur beschrieben, was die Fehlermeldung war, sondern auch, wie es aufspüren.
InformationsquelleAutor OrangeDog

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.