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" <[email protected]> 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.
