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: qed...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to