Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator
On 20/05/2013 01:41, Martin Gainty wrote: Hi Jesse Jesse - please ignore Martin's reply. As usual, he is talking nonsense. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator
On 19/05/2013 17:39, jieryn wrote: Greetings, I am using Apache Tomcat 7.0.40, via IBM Java 7 SR2. I am seeing the following on Tomcat shutdown: org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [com.sun.xml.bind.v2.runtime.Coordinator$1] (value [com.sun.xml.bind.v2.runtime.Coordinator$1@f9b00906]) and a value of type [java.lang.Object[]] (value [[Ljava.lang.Object;@3d8d9b93]) 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. When I inspect the libraries within the application I find: $ grep com.sun.xml.bind.v2.runtime.Coordinator * Binary file jaxb-impl-2.2.1.1.jar matches Apache Maven dependency:tree shows that this is coming from Apache Wink (wink-common - wink-client). Is this JAXB ThreadLocal something that Apache Tomcat ought to protect me from? No. Tomcat is not responsible for any ThreadLocals your application creates. If your application creates them (or causes them to be created), your application needs to clean them up. Depending on exactly what triggers the creation of this ThreadLocal and how it is used, there may be something we can add to Tomcat's JreMemoryLeakProtectionListener to avoid this memory leak. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator
Greetings,
On Mon, May 20, 2013 at 4:17 AM, Mark Thomas ma...@apache.org wrote:
Tomcat is not responsible for any ThreadLocals your application creates.
If your application creates them (or causes them to be created), your
application needs to clean them up.
Ok, I understand.
Depending on exactly what triggers the creation of this ThreadLocal and
how it is used, there may be something we can add to Tomcat's
JreMemoryLeakProtectionListener to avoid this memory leak.
I asked on the Apache Wink user list for assistance explaining the use
of this com.sun.xml.bind.v2.runtime.Coordinator and how I can protect
against a memory leak with application loop { deploy/redeploy/undeploy
} common for web applications.
If I hear back with any leads for Apache Tomcat to explore I will post here.
Thanks,
-Jesse
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator
2013/5/19 jieryn jie...@gmail.com:
Greetings,
I am using Apache Tomcat 7.0.40, via IBM Java 7 SR2. I am seeing the
following on Tomcat shutdown:
org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks
The web application [] created a ThreadLocal with key of type
[com.sun.xml.bind.v2.runtime.Coordinator$1] (value
[com.sun.xml.bind.v2.runtime.Coordinator$1@f9b00906]) and a value of
type [java.lang.Object[]] (value [[Ljava.lang.Object;@3d8d9b93]) 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.
When I inspect the libraries within the application I find:
$ grep com.sun.xml.bind.v2.runtime.Coordinator *
Binary file jaxb-impl-2.2.1.1.jar matches
Apache Maven dependency:tree shows that this is coming from Apache
Wink (wink-common - wink-client).
Where the jar is located?
IIRC the JRE provides a JAXB implementation, so if you replace one,
shouldn't the jar go into ${catalina.home}/endorsed ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator
Greetings,
On Mon, May 20, 2013 at 9:45 AM, Konstantin Kolinko
knst.koli...@gmail.com wrote:
2013/5/19 jieryn jie...@gmail.com:
$ grep com.sun.xml.bind.v2.runtime.Coordinator *
Binary file jaxb-impl-2.2.1.1.jar matches
Apache Maven dependency:tree shows that this is coming from Apache
Wink (wink-common - wink-client).
Where the jar is located?
IIRC the JRE provides a JAXB implementation, so if you replace one,
shouldn't the jar go into ${catalina.home}/endorsed ?
Apache Wink's POM lists it as a dependency, and so it goes right into
the application's WEB-INF/lib. I believe you are right, with Java 6 SE
and up, there is a JAX-B 2.0 implementation bundled. I hadn't tried to
operate without it, even though it seems like I should be able to do
so..
Do you think that this is related to Apache Wink creating a
ThreadLocal, though? The core problem I am trying to address now is
that there may be a memory leak by using a ThreadLocal by Apache Wink.
I contacted them, hopefully they will respond.
-Jesse
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator
Hi Jesse you can configure your customised Jaxb factory implementor by implementing a jaxb.properties file with a javax.xml.bind.context.factory=value javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory be aware with key=value value is the name of the class that implements the createContext for Jaxb http://docs.oracle.com/javaee/5/api/javax/xml/bind/JAXBContext.html Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sun, 19 May 2013 12:39:12 -0400 Subject: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator From: jie...@gmail.com To: users@tomcat.apache.org Greetings, I am using Apache Tomcat 7.0.40, via IBM Java 7 SR2. I am seeing the following on Tomcat shutdown: org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [com.sun.xml.bind.v2.runtime.Coordinator$1] (value [com.sun.xml.bind.v2.runtime.Coordinator$1@f9b00906]) and a value of type [java.lang.Object[]] (value [[Ljava.lang.Object;@3d8d9b93]) 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. When I inspect the libraries within the application I find: $ grep com.sun.xml.bind.v2.runtime.Coordinator * Binary file jaxb-impl-2.2.1.1.jar matches Apache Maven dependency:tree shows that this is coming from Apache Wink (wink-common - wink-client). Is this JAXB ThreadLocal something that Apache Tomcat ought to protect me from? Thank you, -Jesse - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
