Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 39966 invoked from network); 16 Sep 2008 14:55:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Sep 2008 14:55:10 -0000 Received: (qmail 87538 invoked by uid 500); 16 Sep 2008 14:55:04 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 86501 invoked by uid 500); 16 Sep 2008 14:55:02 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 86473 invoked by uid 99); 16 Sep 2008 14:55:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Sep 2008 07:55:02 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Sep 2008 14:54:12 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DB411234C1DF for ; Tue, 16 Sep 2008 07:54:44 -0700 (PDT) Message-ID: <614011676.1221576884897.JavaMail.jira@brutus> Date: Tue, 16 Sep 2008 07:54:44 -0700 (PDT) From: "Ivan (JIRA)" To: dev@geronimo.apache.org Subject: [jira] Issue Comment Edited: (GERONIMO-3838) memory (probably related to sessions) leak In-Reply-To: <27254062.1202759648529.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/GERONIMO-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631422#action_12631422 ] xuhaihong edited comment on GERONIMO-3838 at 9/16/08 7:54 AM: --------------------------------------------------------- I do some change in the ManagerGBean, so that it can could hander the initialization while set the className with org.apache.catalina.session.PersistentManager. For example : TomcatManager org.apache.catalina.session.PersistentManager maxActiveSessions=10 maxIdleBackup=10 maxIdleSwap=11 minIdleSwap=5 store.className=org.apache.catalina.session.FileStore store.checkInterval=10 store.directory=d:/testFolder/session We could set store.className=org.apache.catalina.session.JDBCStore to use the JDBCStore. One thing makes me confusion is that I found the reference name of manager and cluster in the TomcatWebAppContext.java is changed in the patch GERONIMO-3696, and it has conflict with the xml schema file http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1. I change those two reference name back, or it seems that the manager object could not be set. I am not sure whether I miss something, thanks very much for any comment ! was (Author: xuhaihong): I do some change in the ManagerGBean, so that it can could hander the initialization while set the className with org.apache.catalina.session.PersistentManager. For example : TomcatManager org.apache.catalina.session.PersistentManager maxActiveSessions=10 maxIdleBackup=10 maxIdleSwap=11 minIdleSwap=5 store.className=org.apache.catalina.session.FileStore store.checkInterval=10 store.directory=d:/testFolder/session We could set store.className=org.apache.catalina.session.JDBCStore to use the JDBCStore. One thing makes me confusion is that I found the reference name of manager and cluster in the TomcatWebAppContext.java is changed in the patch GERONIMO-3696 is changed, and it conflicts with the xml schema file http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1. I change those two reference name back, or it seems that the manager object could not be set. I am not sure whether I miss something, thanks very much for any comment ! > memory (probably related to sessions) leak > ------------------------------------------ > > Key: GERONIMO-3838 > URL: https://issues.apache.org/jira/browse/GERONIMO-3838 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Memory Leaks, Tomcat > Affects Versions: 2.0.2, 2.1.1 > Environment: tested with JDK 1.5 running on Windows XP and FreeBSD6.2 > Reporter: Radim Kolar > Priority: Critical > Fix For: 2.2 > > Attachments: Geronimo-3838.patch > > > There is memory leak and it can be repeated very easily, so it should be very easy to catch > Install Geronimo and then run some kind of benchmarking software against its admin UI login page, for example > program ab from Apache HTTP. This is realistic attack scenario, because lot of denial of service attacks are doing this (requesting one page many times). > Watching memory used graph in admin console shows free memory slowly decreasing. After all available memory is exhausted, application server stops serving new requests and never restores ifself back to working state. > I think that it is caused by allocating sessions without limiting total number of sessions to keep in memory and possibly to swap sessions out to file. There needs to be user-configurable setting for preventing this, it would be nice to add such setting to Admin console. > Its very important to get this bug fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.