[Bug 58074] New: Memory leak - session serialization

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58074

            Bug ID: 58074
           Summary: Memory leak - session serialization
           Product: Tomcat 7
           Version: 7.0.62
          Hardware: PC
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: qedisk@gmail.com

Created attachment 32853
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=32853&action=edit
SSCCE

Scenario: I have enabled session serialization on
stop+start/reload/undeploy+deploy for my ROOT.war by adding <Manager
pathname="${catalina.base}/ROOT-sessions.ser" /> into
/webapp/META-INF/context.xml in my application. My sessions for my app are
de/serialized properly. But when my custom object implementing Serializable is
stored in some session, then after stop, reload or undeploy and "Find leaks" in
manager console I get a message: "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): /". With
non-serializable objects in session there is no problem (of course, I have to
have disabled <distributable />). According to mailing list, this is not a bug,
but I don't believe it: http://bit.ly/1HbBzrJ . Currently it seems that I have
only one option: to restart a service after undeploy to prevent memory leaks.
I'd like to work without service restarting, if it is possible. My application
has <distributable /> in web.xml. I'm using latest Tomcat 7 + latest JDK 7 +
Win 7 Pro 64. I don't know if bug persists in Tomcat 8. The serializable object
is very simple (see attached SSCCE):

public class SessionUser implements Serializable {
  public SessionUser() {}
  public String toString() { return "xx"; }
}.

The question is: Is it possible to have session serialization enabled (and have
serializable objects in session) and do redeploy without service restart while
no memory leaks happens?

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 58074] Memory leak - session serialization

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58074

--- Comment #2 from qedisk@gmail.com ---
(In reply to Mark Thomas from comment #1)
> A profiler confirms that there is no memory leak here. weak references !=
> memory leaks. GC will clear them as/if necessary to relieve memory pressure.

I must confirm that you are correct. I didn't believe it, but multiple
redeployment of my app showed PermGen space growth UNTIL MAX limit was reached
(I pressed "Perform GC" in the meantime as much as I could - with no effect)
and then, SUDDENLY when the crucial reload was made - the one I hoped to crash
Tomcat - ALL PermGen space occupied by "leaks" was freed AND "Find leaks"
button suddenly showed "No web applications appear to have triggered a memory
leak". I must be more careful next time with issuing bug reports. Thanks for
answer.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 58074] Memory leak - session serialization

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58074

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED
                 OS|                            |All

--- Comment #1 from Mark Thomas <ma...@apache.org> ---
A profiler confirms that there is no memory leak here. weak references !=
memory leaks. GC will clear them as/if necessary to relieve memory pressure.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org