[
https://issues.apache.org/jira/browse/GERONIMO-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan updated GERONIMO-3838:
---------------------------
Attachment: Geronimo-3838.patch
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 :
<manager>TomcatManager</manager>
<gbean name="TomcatManager" class="org.apache.geronimo.tomcat.ManagerGBean">
<attribute
name="className">org.apache.catalina.session.PersistentManager</attribute>
<attribute name="initParams">maxActiveSessions=10
maxIdleBackup=10
maxIdleSwap=11
minIdleSwap=5
store.className=org.apache.catalina.session.FileStore
store.checkInterval=10
store.directory=d:/testFolder/session</attribute>
</gbean>
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.
