Throw Tomcat Session to Avoid OutOfMemoryError

Question

We run the vendor-supplied webapp in Tomcat 5.5 using the standard session manager (in-memory). Since sessions can become quite large (20M +), running out of heap space is a serious concern. Users want to keep sessions for hours, if possible, but are more likely to evict sessions than end up with a ton of space. It does not seem that the provider correctly implemented Serializable in session objects, so switching to implementing a permanent session manager is not an option.

Tomcat allows you to set the maxActiveSessions property, which will limit the total number of sessions in the manager. However, when this limit is reached, no new sessions can be created before the expiration of existing sessions. We want to photograph the least recently used sessions first.

Ideally, we would like to end some recently used sessions when heap usage approaches the Xmx setting, even if they are not old enough to expire unconditionally. A very old version of the Tomcat developer mailing list suggested that this might allow a denial of service * attack, but since this application is only available on the corporate network, we do not care.

I was thinking of expanding StandardManager to override processExpires () and additional clobber sessions if the heap usage is greater than, say, 85% of max. However, in practice this seems a little problematic. What if muuch from the heap is not specified, and the garbage collector can collect a ton of objects (if it is tired of working) to reduce the heap to 50% of the maximum? I would torment sessions unnecessarily. I think we could mitigate this risk with some aggressive garbage collection settings. Also, how can I find out how much memory I saved by ending a session? I would have to wait a few GC cycles to know for sure. Perhaps I could take a conservative approach and delete no more than N sessions per background process cycle until the memory drops below an acceptable threshold. I could serialize the session as a way to estimate how much material GC'ed will be, but it depends on the provider implementing Serializable and marking the instance variables as transient, respectively.

Has anyone solved this problem? As a short-term fix, we increase the heap size, but this tape help also has its drawbacks.

• They referred to a public site where pre-registration sessions would be created. Someone can create many new sessions and supplant those that are actually used.

Update: We really do not have much control over the system architecture, and we specifically cannot reduce the use of the session. Nevertheless, we can work with the container as much as we want. However, Tomcat is the only open source servlet container supported by vendors.

Answer 1

Your options are as follows:

• reduce idle session timeout,
• make sessions permanent (possibly only after user login),
• reduce the memory used by each session object
• increase memory for your Tomcat instance,
• run several instances of your service and put a load balancer in front of it.

From a technical point of view, 3 is the best solution ... if it works. The rest all have a downside.

Doing smart things with memory is just a streak. From the point of view of users, this makes it difficult to understand the behavior of your site. In addition, if your user base / traffic tends to be up, you only put off the problem of finding a sustainable solution.

Answer 2

Have you tried to increase the maximum JVM heap size?

By default, if not specified, it is only 64 MB, which, I would say, is on the small side for the most intensive / full-blown web applications.

The best way to do this with Tomcat is to add the following to setenv.bat / .sh :

 export CATALINA_OPTS=-Xmx128m 

(replace any value you want with 128 if you want more than 128 MB. Also change the syntax for Windows / your shell)

The startup and catalina shell scripts for Tomcat have built-in logic to call this file if it exists. This is a “best practice” method for specifying any custom environment properties that you need to set for your Tomcat installation — therefore, the properties of this file are better than editing startup.sh or catalina.sh directly, because this file may be portable between installations Tomcat / version.

You may also be interested in this link: 6 General errors when setting the Java heap size (which also has a section at the end How to set the java heap size in Tomcat?).

Answer 3

I would advise front multiple tomcat instances with apache and then use mod_jk to load balance between them.

You can do this without any real clustering, so sharing a session will not be a problem.

Mod_jk is solid rock and even offers a simple gui to mark instances as unusable, etc.

It will also bring many other benefits in terms of sustainability, etc. I personally used this setting on a very large public site, and it worked.

The ideal situation is to set up true session sharing, but in some cases it is too much.

Look here:

http://tomcat.apache.org/connectors-doc/generic_howto/quick.html

Answer 4

“I agree with Stephen C that this is your supplier with whom you need to solve the problem,” he said, even switch vendors. One thing that no one mentioned here (surprisingly) is that the seller should also look at cleaning up unused session objects.

It is very simple if you don’t remember it all the time to allow the size of the session to bloat - to allow the size of the object to bloom unnoticed - then you have a big session, when we have a list of these objects - then we never clear their applications - if the application It is great if in some sections of the application lists of objects A, B, C, D, E, F are displayed, but they are never cleared, which is the main problem in the household that the supplier did not contact.

eg. Is there a "central screen" in webapp where you go to other parts of the application? If this is the case, then the provider should clear when entering on this screen all the objects that would be collected and loaded into the session on the screens accessible from the central page / screen / portal

Edit And use pagination rather than loading all list matching criteria (unless pagination is part of the criteria)

I hope this comment helps you and others.