[
https://issues.apache.org/jira/browse/WICKET-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov reassigned WICKET-6046:
---------------------------------------
Assignee: Martin Grigorov
> 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
> Assignee: Martin Grigorov
>
> 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)
