Uploaded image for project: 'Wicket'
  1. Wicket
  2. WICKET-6046

Wicket Quickstart Example Application shows deployment memory leak in Tomcat

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 7.1.0
    • Fix Version/s: 7.2.0, 8.0.0-M1
    • Component/s: wicket-examples
    • Labels:
      None

      Description

      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/

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                mgrigorov Martin Grigorov
                Reporter:
                rstoeckel René Stöckel
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: