René Stöckel created WICKET-6046:
------------------------------------
Summary: Wicket Quickstart Example Application shows deployment
memory leak in Tomcat
Key: WICKET-6046
URL: https://issues.apache.org/jira/browse/WICKET-6046
Project: Wicket
Issue Type: Improvement
Components: wicket-examples
Affects Versions: 7.1.0
Reporter: René Stöckel
When the Wicket Quickstart is created via
https://wicket.apache.org/start/quickstart.html this basic application runs
nicely with netbeans ee 8.1 and tomcat 8.0.27. However the tomcat option "Find
leaks" in the tomcat manager app complains: "The following web applications
were stopped (reloaded, undeployed), but their classes from previous runs are
still loaded in memory, thus causing a memory leak (use a profiler to confirm):
/testproject". The catalina.log lists one of the reasons. "25-Nov-2015
16:32:16.556 SEVERE [http-nio-8084-exec-2]
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks
The web application [testproject] created a ThreadLocal with key of type
[org.apache.logging.log4j.core.layout.PatternLayout$1] (value
[org.apache.logging.log4j.core.layout.PatternLayout$1@cc293b5]) and a value of
type [java.lang.StringBuilder] (value [2015-11-25 16:32:16,533 INFO
o.a.w.Application [http-nio-8084-exec-2] [wicket.testproject] destroy: Wicket
core library initializer
]) 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."
This is a known log4j bug and can simply be solved by upgrading to log4j
version 2.4.1.
But, Tomcat still can not yet clean the classloader of the wicket example app
and stills shows the memory leak in the manager app. The reason might be, that
one object either in the wicket libraries or other libraries holds a reference
to the class loader.
There seems to be a process to work these kind of problems out as described
here:
https://cdivilly.wordpress.com/2012/04/23/permgen-memory-leak/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
