Currently when a user logs out of my portal, I call the Access Manager ui/Logout page to kill the users session and drop them out of portal.
However, it seems that this does not clean up any items they may have had sitting in memory (heap/JVM/etc). Is there anyway to force this to happen, or is it not necessary and the garbage collection of the jvm (in this case hotspot) supposed to know those objects are now dead?
You are right, the garbage related to the users who have logged out is not cleaned up. And that is fine. The garbage collection cycles happen when certain usage thresholds are met, not when objects are marked as null.
This, in fact, is much better than having the garbage collection triggered by an event such as the setting of a variable (no matter how large) to null. The garbage collection (even the one that only covers the new generation) is very expensive, so it is best to minimize the number of occurances.
And, in any case, most of the long lived session data has likely been moved to the old generation and GC cycles that cover the old generation (CMS cycles for newer JVMs) are definitely something you don't want to trigger just because a bit of memory was freed up.
So, long story short.... Everything is fine and working as it is supposed to.
That sounds fine then, except I am running out of JVM memory. I have allocated 3.5 gigs to it, and run through it from time to time. I typically am able to find items that are just bigger than they need to be, but when you have a few hundred users logged in viewing up to 20 portlets at a time, it is not hard to get gigs and gigs of stored data. Cleaning it ASAP is sometimes required.
Or maybe I am thinking about this the wrong way?
I have a single portal with 30 users who have some subset of 10 portlets available to them. Each of these portlets could be sizable after it provides db driven drop downs, etc. Nothing too big, but every once in a while a session bean may be storing a a few thousand rows from a table. Now, since each portlet has its own session bean, I could be getting lots of storage really quickly. What am I to do?
Let's be very clear about what exactly it means to: "running out of JVM memory". Are you seing Out of Memory Exceptions? If so, then either a) there is a memory leak or b) the data set is genuinely too large to fit in 3 GB (unlikely).
So at that point you want to start digging into the JVM logs. Setup your JVM so that it has the following options:
<jvm-options>-Xms3136M -Xmx3136M</jvm-options>
<jvm-options>-Xss128K</jvm-options>
<jvm-options>-Xloggc:/tmp/gc.log</jvm-options>
<jvm-options>-XX:NewSize=392M</jvm-options>
<jvm-options>-XX:MaxNewSize=392M</jvm-options>
<jvm-options>-XX:+DisableExplicitGC</jvm-options>
<jvm-options>-XX:+UseParNewGC</jvm-options>
<jvm-options>-XX:+UseConcMarkSweepGC</jvm-options>
<jvm-options>-XX:+PrintClassHistogram</jvm-options>
<jvm-options>-XX:+PrintGCTimeStamps</jvm-options>
Then look at the file /tmp/gc.log. Here the proof of a memory leak (or not enough memory) is given by the interval between, duration and efficiency of the CMS events. Basically does the CMS happen ever more frequently, does it always clean less and less? Or will it eventually stabilize? In my tests after a few hours of load cycles, the GC activity will reach a point of stability where the CMS events happen at a consistent interval and the memory available after the CMS event is always more or less the same.
At least, that's where I would start...
