You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@avro.apache.org by Chris Wilkes <cw...@gmail.com> on 2011/06/09 20:59:12 UTC

Tomcat complaining about Schema threadlocal not being removed

My webapp accepts HTTP POSTs of avro files and I ran into this when
redeploying:

SEVERE: The web application [/mywebapp] created a ThreadLocal with key of
type [org.apache.avro.Schema$2] (value [org.apache.avro.Schema$2@164a40a0])
and a value of type [java.util.IdentityHashMap] (value [{}]) but failed to
remove it when the web application was stopped. This is very likely to
create a memory leak.

Looking at the Schema code it looks like SEEN_EQUALS and SEEN_HASHCODE are
the culprits.

Has anyone else run into this?

http://wiki.apache.org/tomcat/MemoryLeakProtection#customThreadLocal

Re: Tomcat complaining about Schema threadlocal not being removed

Posted by Matt Pouttu-Clarke <Ma...@icrossing.com>.
Hi Chris,

I don¹t know if this will fix this issue, but you can try using the
ServletContext instead of a servlet instance variable:
http://download.oracle.com/javaee/1.4/tutorial/doc/Servlets4.html

Usually works for me instead of thread local.  However, I¹m not sure it will
fix a nested library using a thread local or not.  Theoretically, if the
reference is not reachable it should be cleaned up by the garbage collector
when the web app restarts, so try setting the servlet context variable to
null as well to see if that cleans up this issue.

Cheers,
Matt

FYI: hopefully you are aware that HTTP is a text protocol that converts all
binary to text, so nesting a binary protocol in a text protocol is so
inefficient, you might as well be using JSON rather than Avro...

On 6/9/11 11:59 AM, "Chris Wilkes" <cw...@gmail.com> wrote:

> My webapp accepts HTTP POSTs of avro files and I ran into this when
> redeploying:
> 
> SEVERE: The web application [/mywebapp] created a ThreadLocal with key of type
> [org.apache.avro.Schema$2] (value [org.apache.avro.Schema$2@164a40a0]) and a
> value of type [java.util.IdentityHashMap] (value [{}]) but failed to remove it
> when the web application was stopped. This is very likely to create a memory
> leak.
> 
> Looking at the Schema code it looks like SEEN_EQUALS and SEEN_HASHCODE are the
> culprits.
> 
> Has anyone else run into this?  
> 
> http://wiki.apache.org/tomcat/MemoryLeakProtection#customThreadLocal
> 
> 
> 


iCrossing Privileged and Confidential Information
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information of iCrossing. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.