On 2011-01-26 12.20, Dag Blakstad wrote:
Hi!
Seems like there is a couple of thread locals that are not cleaned up
upon finishing off. Tomcat logs these as severe, and we have been
experiencing hangs/OutOfMemory in our testenvironment the last couple of
days,
26-Jan-2011 02:17:01 org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type
[org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value
[org.apache.solr.schema.DateField$ThreadLocalDateFormat@1bb334a]) and
a value of type
[org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat] (value
[org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a])
but failed to remove it when the web appli
cation was stopped. To prevent a memory leak, the ThreadLocal has been
forcibly removed.
I have added a fix in the embedded Solr service which clears this.
26-Jan-2011 11:09:32 org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
SEVERE: A web application created a ThreadLocal with key of type [null]
(value [org.qi4j.api.util.DateFunctions$2@1b93c4c]) and a value of type
[java.text.SimpleDateFormat] (value [java.text.SimpleDa
teFormat@5af7aed5]) but failed to remove it when the web application was
stopped. To prevent a memory leak, the ThreadLocal has been forcibly
removed.
26-Jan-2011 11:09:32 org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap
This one is a bit tricky. How could we know that this threadlocal should
be killed, as in remove the threadlocal entirely? Upon
Application.passivate()? What if Application.activate() is called again,
then it would break!
In other words, what is the correct way to handle lifecycle of a static
Threadlocal, so that the classloader can be collected? I have no idea
really I must admit...
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
