Dear Todd,
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.
JMX offers quite a bit of insight in what your GC is doing. You could
implement throttling
> From: André Warnier [mailto:a...@ice-sa.com]
> Thanks, Chuck and Peter, for the clarifications on OOM.
> I believe that unconsciously, with my "large object
> reservation" theory,
> I was vaguely remembering something I had read some time in the past.
> So I searched Google for "java +parachute +
Thanks, Chuck and Peter, for the clarifications on OOM.
I believe that unconsciously, with my "large object reservation" theory,
I was vaguely remembering something I had read some time in the past.
So I searched Google for "java +parachute +memory" and this is something
I found :
http://mail-
> From: Todd Hivnor [mailto:spambox_98...@yahoo.com]
> Subject: Re: Preventing OutOfMemoryError: Java heap space
>
> In my tests, as the RAM becomes depleted, the server
> response becomes slower and slower.
That's because you're going through garbage collecti
On 13.05.2009 08:07, Peter Crowther wrote:
>> From: André Warnier [...@ice-sa.com] would it not be easier to catch
>> the OOM exception and then return a "sorry, server overloaded" page
>> to the browser ?
>
> At that point, it's too late. A thread, somewhere in the system,
> tried to allocate so
> From: Todd Hivnor [mailto:spambox_98...@yahoo.com]
> 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
> From: André Warnier [...@ice-sa.com]
> would it not be easier to catch the OOM exception and then return a
> "sorry, server overloaded" page to the browser ?
At that point, it's too late. A thread, somewhere in the system, tried to
allocate some memory for an object and couldn't. This could h
>> 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.
> From: André Warnier [mailto:a...@ice-sa.com]
> Subject: Re: Preventing OutOfMemoryError: Java heap space
>
> > I'm going to add an explicit request for garbage
> > collection, _before_ the memory becomes seriously
> > depleted.
To the OP: explicitly callin
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 moni
>> 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 monito
> 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, w
I think the results are going to be pretty erratic.
The issue that I see is that the garbage collector operation is (to my
knowledge) not deterministic.
IOW, you're not really accounting for memory that could be garbage
collected. So, I think that you'll have a systematic bias showing less
m
13 matches
Mail list logo
