>> But would it not be easier to catch the OOM exception and then
>> return a "sorry, server overloaded" page to the browser ?
> It's difficult to do that when the OOME may occur in Tomcat code,
> outside of control of the webapp.
Wow I had assumed I could always catch this type of exception.
Thanks for clarifying.
In any case, tho, I specifically don't want the OOME exception to occur,
largely because it takes so much _time_ to occur. In my tests, as the RAM
becomes depleted, the server response becomes slower and slower.
The actual OOME takes over a minute to appear. Apparently the JVM
is making a heroic effort to satisfy the request.
>> (I would mischievously also add a suggestion to buy some more RAM,
>> as an even cheaper alternative).
>That's the only reasonable solution, if the OP is unwilling to
> implement the throttling Peter suggested.
Yes of course I can throw more RAM at the problem.
But I would still like to have a graceful response to the
"overloaded" scenario. More RAM is just delaying the
problem.
I was hoping there was a simple solution I had overlooked.
One challenge with Peter's suggestion of tracking the
number of sessions myself is that I have a collection
of webapps. So I can't just set up a shared static counter;
I need a counter which works across multiple webapps.
The only way I know to do that is to use a text file,
and take care about locking the file before updating it.
Or perhaps I can use ServletContext.
Overall session counting sounds like my best option.
Again, thanks for all the clues & suggestions.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
