Security in web container (Tomcat): Possible memory leak?

[raffaele.ragni]

Hi, i've been testing some few things with spring security and it seems there is a strange behavior on redeployment/undeployment of a web app using authentication. I gave a peek at the first 5 pages of the threads here and couldn't find anyone mentioning a memory leak in their title. Yet not sure if it's a known issue.

The point is: I've created a plain simple web project with maven, added spring security (config + web) dependencies and let it resolve the rest. Packaged the app in war, and deployed through the tomcat manager panel.

Undeploying and redeploying the application causes a possible memory leak (using the 'find leak' button in the manager panel), but the leak seems appear only if the web app is accessed at least once (ie. by url), and then undeployed.
Doing it two times in a row gives a double entry in the 'leak' list, so it's clearly something that adds up in memory, and thus not reusing any portion of it.
Though, after roughly 15 minutes, it seems to wander off. If it could be dependant on the session, I would've at least had to wait for 30 minutes (checked the default Tomcat config, it's 30 minutes for session timeout), and not 15.
This seems to be a minor issue then, but I'm not yet sure if in a production environment, a redeployment within those 15 minutes would leave the instances up in memory or not, not even sure how to test deeply that though.
And i also ignore how actually Tomcat is cleaning things up there, so not even sure if I'm posting in the right place...

Attached is a project that could reproduce these behaviors.
The project is very simple, and uses the user database as a built in configuration in the spring xml file.
Didn't even wrote any Java class there.

I've used: tomcat 6.0.26, maven3, and the attached project.
Spring security version chosen was 3.0.5-RELEASE
- 'mvn package'd the war,
- Started tomcat normally,
- logged in in the manager console,
- deployed the war from there,
- accessed the webapp,
- undeployed the web application,
- clicked the find leak button.

May someone check if I am right?

[Luke Taylor]

6.0.26 is an old version of tomcat 6. I would at least try with the latest version and make sure you have the same issue before pursuing it further.

[raffaele.ragni]

Tried with Tomcat 6.0.32, and 7.0.14. Both freshly downloaded.
Same results.

[Rob Winch]

Did you try using a profiler to confirm the leak as the Tomcat Find Leak message suggests? What are the results? Do you exclude weak/soft references to the ClassLoader? If you are unfamiliar with how to profile the application, you can try Eclipse MAT, YourKit, etc.

When I profiled the application you posted there are only Soft/Weak references holding on to the ClassLoader. Many of the references were internal to the JVM/Tomcat and as far as I am aware unavoidable from Spring Security's standpoint. For example:

[Weak/Soft Reachable] org.springframework.security.web.savedrequest.DefaultSavedRequest
  referent of java.io.ObjectStreamClass$FieldReflectorKey
    key of java.util.concurrent.ConcurrentHashMap$HashEntry
      [0] of java.util.concurrent.ConcurrentHashMap$HashEntry[4]
        table of java.util.concurrent.ConcurrentHashMap$Segment
          [14] of java.util.concurrent.ConcurrentHashMap$Segment[16]
            segments of java.util.concurrent.ConcurrentHashMap
              reflectors of java.io.ObjectStreamClass$Caches [Class]

There are other Soft/Weak references within Spring in general that may be able to be cleaned up. However, it should be noted that Soft/Weak references are allowed to be garbage collected at any time.

In short, the behavior I am seeing is that the Garbage Collector can reclaim the space, but has not chosen to do so yet. This is causing Tomcat to give a false positive on the leak.

HTH,

[raffaele.ragni]

I've tested it another time...
Tried this time to redeploy the webapp before the 10 minutes (it's 10).
Then, waited 10 minutes anyway, with the app running, and the leak was still gone.

So it seems enough it's a false positive, even without dumping all the memory.
Not sure why it waits for 10 minutes, but thanks for the help.