You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/05/30 11:57:12 UTC

[jira] [Commented] (WICKET-6046) Wicket Quickstart Example Application shows deployment memory leak in Tomcat

    [ https://issues.apache.org/jira/browse/WICKET-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306570#comment-15306570 ] 

ASF subversion and git services commented on WICKET-6046:
---------------------------------------------------------

Commit e640cfd021128d7ee24b5addf4bff41412407187 in wicket's branch refs/heads/master from [~mgrigorov]
[ https://git-wip-us.apache.org/repos/asf?p=wicket.git;h=e640cfd ]

WICKET-6046 Wicket Quickstart Example Application shows deployment memory leak in Tomcat

LOG4J2-1222 Initializing Logger during JVM shutdown fails with FATAL error


> 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
>             Fix For: 7.2.0, 8.0.0-M1
>
>
> 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)