You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by jieryn <ji...@gmail.com> on 2013/05/19 18:39:12 UTC

checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator

Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator

Posted by Martin Gainty <mg...@hotmail.com>.
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: jieryn@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
 		 	   		  

Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator

Posted by jieryn <ji...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator

Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator

Posted by jieryn <ji...@gmail.com>.
Greetings,

On Mon, May 20, 2013 at 9:45 AM, Konstantin Kolinko
<kn...@gmail.com> wrote:
> 2013/5/19 jieryn <ji...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: checkThreadLocalMapForLeaks: com.sun.xml.bind.v2.runtime.Coordinator

Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/5/19 jieryn <ji...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org