Todd Hivnor wrote:
From: Todd Hivnor [spambox_98...@yahoo.com]
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
stupid.
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
