tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Preventing OutOfMemoryError: Java heap space
Date Tue, 12 May 2009 22:25:52 GMT
Todd Hivnor wrote:
>>> From: Todd Hivnor []
>>> I would like to proactively avoid running out of heap
>>> space. I would like people get a "Server Too Busy"
>>> message, _before_ the heap is actually exhausted.
>>> I would rather serve 40 users well than 45 users
>>> poorly.
>> Rather than monitor memory, which is subject to GC
>> whims as George points out, I'd suggest monitoring 
>> the number of sessions in your  application - find a 
>> number of sessions you can live with, keep a (suitably 
>> synchronized) counter that's incremented and decremented 
>> as  sessions are created and destroyed, and don't start
>> new sessions if that counter is higher than your threshold.
>> - Peter
> Peter / George, thanks for the input. 
> I'm not sure I can use session counting, as my
> session size is not consistent. I could try to estimate 
> the size of each session, and keep a global counter,
> but that seems like a lot of work. 
> I understand that garbage collection is, err, whimsical, 
> but I think I'm going to give it a go anyway.
> I will keep in mind that the memory results
> from Runtime will probably under-report the
> available memory. I'm going to add an explicit
> request for garbage collection, _before_ the memory 
> becomes seriously depleted. 
> Thanks for the suggestions!
Sorry for jumping in as a naive and frankly incompetent java and Tomcat 
programmer, and do not feel obliged to respond if the question is really 
But would it not be easier to catch the OOM exception and then return a 
"sorry, server overloaded" page to the browser ?
(and maybe then also trigger a GC just for tidiness)

Or a more ambitious scheme : at Tomcat startup, a thread is created 
which immediately allocates some largish object and keeps it.  Then this 
thread starts listening for OOM exceptions (I just imagine that this can 
be done).  When one occurs, the thread releases the object and triggers 
a GC.  Then it tries to allocate the object again.  Then.. I'm running 
out of ideas and technique.  It was just a thought, in the direction of 
making GC a bit more deterministic.

(I would mischievously also add a suggestion to buy some more RAM, as an 
even cheaper alternative).

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message