[
https://issues.apache.org/jira/browse/GERONIMO-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593919#action_12593919
]
Radim Kolar commented on GERONIMO-3838:
---------------------------------------
using Sun hat tool i can confirm that this problem is related to allocating lot
of sessions.
dump from HAT tool
Instance Counts for All Classes (excluding platform)
466128 instances of class [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
83106 instances of class [C
36330 instances of class [Ljava.lang.Object;
30464 instances of class [Ljava.util.Hashtable$Entry;
29133 instances of class [Ljava.util.concurrent.ConcurrentHashMap$Segment;
29086 instances of class org.apache.catalina.session.StandardSession
29086 instances of class org.apache.catalina.session.StandardSessionFacade
There is difference between using IBM vs SUN JDK, If Sun jdk is used Geronimo
never recovers from out of memory error.
Proposed fix:
Geronimo needs to swap inactive sessions to file or forget them and not to
run out of memory. It would be nice to have number of sessions kept in main
memory configurable via System configuration console.
> 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
> Affects Versions: 2.0.2
> Environment: tested with JDK 1.5 running on Windows XP and FreeBSD6.2
> Reporter: Radim Kolar
> Priority: Critical
>
> 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.
