1. Zuhause
  2. Frage und Antwort
  3. Was sind diese Warnungen in catalina.out?

Was sind diese Warnungen in catalina.out?

2012-04-03 5 views
13

Ich habe eine Web-Anwendung in Tomcat 7.
Wenn ich Tomcat heruntergefahren Ich sehe diese Warnung (aber nicht immer)Was sind diese Warnungen in catalina.out?

SEVERE: The web application [/MyApplication] created a ThreadLocal 
with key of type 
[org.apache.xml.security.algorithms.MessageDigestAlgorithm$1] (value 
[[email protected]2e2c]) 
and a value of type [java.util.HashMap] (value 
[{http://www.w3.org/2000/09/xmldsig#sha1=MESSAGE DIGEST SHA-1}]) but 
failed to remove it when the web application was stopped. Threads are 
going to be renewed over time to try and avoid a probable memory leak. 
Apr 3, 2012 1:56:19 PM org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks SEVERE: The web application 
[/MyApplication] created a ThreadLocal with key of type 
[com.sun.xml.bind.v2.ClassFactory$1] (value 
[[email protected]]) and a value of type 
[java.util.WeakHashMap] (value [{class 
[email protected]b17eb, 
class 
javax.xml.bind.a[email protected]178a178a, 
class 
[email protected]1c181c, 
class 
c[email protected]17711771, 
class 
c[email protected]17011701}]) 
but failed to remove it when the web application was stopped. Threads 
are going to be renewed over time to try and avoid a probable memory 
leak. Apr 3, 2012 1:56:19 PM 
org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks SEVERE: The web application 
[/MyApplication] created a ThreadLocal with key of type 
[org.apache.xml.security.utils.UnsyncBufferedOutputStream$1] (value 
[[email protected]a90]) 
and a value of type [byte[]] (value [[[email protected]]) but failed to 
remove it when the web application was stopped. Threads are going to 
be renewed over time to try and avoid a probable memory leak.

Was beim Herunterfahren bedeuten diese Warnungen in catalina.out?
Ich sehe einige meiner JAXB-Klassen erwähnt, kann aber nicht sagen, was das Problem hier ist.

Irgendwelche Hilfe bitte?

Quelle

2012-04-03 Jim

Antwort

23

Auf den Punkt gebracht, einige ThreadLocals nicht richtig gereinigt worden. Die meisten (wenn nicht alle) J2EE-Server/Anwendungscontainer verwenden Threadpools für eingehende Anforderungen und andere Aufgaben, um den Overhead beim Starten neuer Threads zu vermeiden. Das Problem ist, dass einige Bibliotheken (und Sie selbst, wenn Sie es nicht besser wissen) ihre ThreadLocals nicht bereinigen, nachdem die Ausführung der Aufgabe/Anforderung beendet wurde.

Normalerweise, da die Gewinde an Ende der Ausführung stirbt, die in ThreadLocals gespeicherten Objekte sind nicht mehr referenziert und der Garbage Collector kümmert solche Gegenstände zum Entfernen von:

Jeder Thread seine Kopie eine implizite Referenz hält einer Thread-lokalen -Variablen, solange der Thread aktiv ist und die ThreadLocal-Instanz zugänglich ist; Nach dem Entfernen eines Threads werden alle Kopien der threadlokalen Instanzen einer Speicherbereinigung unterzogen (sofern nicht andere Verweise auf diese Kopien vorhanden sind).

Wenn der Thread jedoch aus einem Thread-Pool abgerufen wurde, wird er nicht gelöscht, sondern an den Pool zurückgegeben. Da der Thread noch am Leben ist, sind auch die referenzierten ThreadLocals. Dies manifestiert sich sowohl als Speicherlecks als auch als "Leaking" von Werten von einer Anfrage zur anderen, wenn das gleiche ThreadLocal verwendet wird und der Thread, der die Anfrage/Aufgabe behandelte, zuvor verwendet wurde.

Quelle

2012-04-04 19:06:04 esaj

+0

+ 1.Ich benutze keine Thread-Locals in meinem Code.Wie kann ich mehr darüber lesen? – Jim

+1

@Jim Siehe hier für die Überwachung: http://tomcat.apache.org/tomcat-7.0-doc/monitoring.html, nachdem Sie die JMX-Fernbedienung aktiviert haben, können Sie beispielsweise JConsole (kommt mit JDK) verwenden, um darauf zuzugreifen. Die ThreadLocals stammen wahrscheinlich aus einer Bibliothek, die Sie verwenden. Als wilde Vermutung, da diese Warnungen nicht immer angezeigt werden, ist es möglich, dass einige Bibliotheken beim Herunterfahren der Anwendung etwas tun, sodass Tomcat * möglicherweise falsche positive Ergebnisse liefert. Wenn die Speicherauslastung der Anwendung im Laufe der Zeit nicht wächst, wenn sie für längere Zeit in Betrieb ist und Sie nicht häufig neu bereitstellen, würde ich mich nicht so sehr darum kümmern. – esaj

10

Mindestens eine der JAXB Nachrichten erscheint auf einen bekannten Fehler zu beziehen:

org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SCHWEREN: Die Web-Anwendung [/ MyApplication] eine Thread erstellt mit Schlüssel des Typs [com.sun.xml.bind.v2.ClassFactory $ 1] (Wert [[email protected]]) und ein Wert vom Typ [java.util.WeakHashMap ]

Siehe JAXB-563 und JAXB-831 (NB - Diese sind auf java.net und erfordern eine Anmeldung, um sogar anzuzeigen). Der erste Bug wurde angeblich behoben, aber wie andere bemerkt haben, ist dies nicht vollständig behoben. Der zweite Fehler hat eine vorgeschlagene Problemumgehung, die ein gc() erzwingen soll, bevor der Kontext heruntergefahren wird, wodurch das Problem gemildert wird (obwohl es nicht vollständig beseitigt wird) - Sie können eine benutzerdefinierte ServletContextListener verwenden und einfach System.gc() in der contextDestroyed()-Methode aufrufen.

Wie für die anderen Fehler müssen Sie die anderen Antworten Rat befolgen und einige ernsthafte Fehlersuche.

Quelle

2013-01-30 15:46:16 RobV

+0

Mann, das scheint mein Problem zu sein, aber ich kann die Anwendung in Tomcat nicht starten, weil es mir diesen Fehler gibt. Ich habe die web.xml bereits mit dem neuen ServletContextListener geändert. Irgendwelche Vorschläge? –

+2

Ich habe dieses Problem bei der Ausführung von Jersey auf Tomcat mit den Datastax Cassandra-Treibern festgestellt. Obwohl ich die Cassandra-Cluster-Verbindung in ContextDestroyed() geschlossen habe, bekam ich immer noch die Threads-/Speicherleck-Fehler, wenn ich die App erneut umstellte. Das Hinzufügen von System.gc() nach dem cluster.close() hat das Problem behoben. –

Verwandte Themen

 Verwandte Themen