Monitoring Glassfish memory usage over time

[miss_duke]

My web application runs on Glassfish server, it works fine except it crashes time to time (about once in a month) after throwing "OutOfMemoryError".

I just want to monitor the memory usage by Glassfish server over time, how can I do that?

Thanks.

[Tomas Hurka]

Hi,

On 15 Jun 2009, at 17:21, miss_duke wrote:

[miss_duke]

Hi,

Are there any ways to save the Glassfish application server from crash on outOfMemoryError?

Can we immediately and automatically empty the contents of the heap on outOfMemoryError? (After making the heap dump)

Thanks.

[Jiri Sedlacek]

Hi,

the OutOfMemoryError means that the heap is full and the garbage collector isn't able to empty it.
If you are using some caches that can eventually be released near to the OOME then use weak/soft
references to hold the caches - the garbage collector will clear the caches if the heap is near to
its limit.

Jiri


miss_duke wrote:

[miss_duke]

If we cannot avoid server crash on outOfMemoryError, this has to be considered a weak point in Java technology. An enterprise production quality technology shouldn't be like that!!
How can we consider Java as the technology for "MISSION CRITICAL" applications?

Thanks.

[Replogle, Andrew]

The weak point is not in java technology but the application you are using.

If you emptied out the heap, you'd make any session attached to the vm completely ineffective rendering the same user experience as a crashed vm.

If you knew which objects to exclusively empty out of the heap and keep everything that's in use, you wouldn't be having this issue as that's what GC does.

There is a garbage collection process that goes and reaps objects no longer referenced. Your issue is either that A) your application footprint is larger then the heap you're providing it or B) your code, or third-party code you're including is not releasing objects after it is done with them. This makes the GC reaper pass over them when it goes to clean up the heap.

You could buy yourself time by forcing a full gc and clearing up some space if there is any to free up, but this is not a solution. You need to take a heap dump, analyze it for leak suspects and fix your application where it's leaking references. Simply altering the environment it runs in is not a solution.

If you're not using session replication and load-balancing in your environment, its not considered enterprise anyway.

I suggest reading the following to gain stronger insight into how to architect and administer your environments:

http://www.codingthearchitecture.com/2008/01/14/jvm_lies_the_outofmemory_myth.html

http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

http://java.sun.com/developer/technicalArticles/J2SE/monitoring/


reference:

http://blogs.sun.com/watt/resource/jvm-options-list.html





-----Original Message-----
From: miss_duke [mailto:address-removed]
Sent: Thursday, September 03, 2009 12:39 AM
To: address-removed
Subject: [profiler] Monitoring Glassfish memory usage over time

If we cannot avoid server crash on outOfMemoryError, this has to be considered a weak point in Java technology. An enterprise production quality technology shouldn't be like that!!

How can we consider Java as the technology for "MISSION CRITICAL" applications?



Thanks.





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


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

[markwright789]

If you are applying some caches that can finally be released near to the OOME then apply weak references to hold the caches the garbage collector will clear the caches if the heap is near to its limit.

[girlsgames]

I'm too

[girlsgames]

I'm too

[zeeshanam]

I am too..