JAVA JMS CLIENT java.lang.OutOfMemoryError

[ANTHONY CREMONA]

We have a TRU64 UNIX with OSF1 OS with the operating system version 4.0F.
We have Java 1.4.2-6 installed on the alpha box. I have recently installed a JMS client
application on this box. The JMS client uses the Spring framework.
we only have limited memory available ,2GB RAM. This box hosts some very critical applications to our company so resources are at a premium.

the JVM arguments i have used for this JMS client are as follows:

java -client -Xms64M -Xmx150M

the memory usage by the JVM starts off well for the first couple of hours in fact it consumes about 130M in resident memory. But 4 hours later it is consuming around 210M in resident memory.

Some time later, maybe a day or two later it generates the error OutOfMemory.

any suggestions to overcome this problem?
any assitance is most appreciated.

thanks

tony

[Rick Retterer]

Tony,
You may want to consider upgrading to the latest version of Java for Tru64 Unix.

The latest version is 1.4.2-8.

http://h18012.www1.hp.com/java/documentation/1.4.2/unix/docs/release_notes.html

The reason I ask is because in Java 1.4.2-7 there were several issues that were addressed that had to do directly with garbage collections that could be related to your problem.

In addition, the process that is running the application, what are it's ulimit values. Are they high enough to give Java what it needs to run without having to do multiple GC's over and over?

Do you make use of the -Xdynclassgc resource to allow Java to recover dynamically allocated classes that accumulate over time in a Java application that runs for long periods of time?

Finally, if you find that the problem continues after looking into the things I've listed above, you may want to capture a session's memory usage by using the
Java -Xverbosegc:file:hpsupport_gc.log -Xms*m -Xmx*m

(-Xverbosegc) memory data collection to provide to the HP Java Support team for analysis. Perhaps they will be able to advise you on what is possibly going on.

And don't forget to check with the vendor for the application, they may already know about the memory leak and they can further advise you on what the possible fix could be.

I hope this gives you some direction.

Cheers,
Rick Retterer

[ANTHONY CREMONA]

Rick,

yes. this certainly gives me some direction.

much appreciate. I will start to work on these suggestions.

thank you.

tony

[Rick Retterer]

You are very welcome.

Cheers,

Rick

[ANTHONY CREMONA]

Hi Rick,

first I have tried the -Xdynclassgc switch. this caused a core dump and a segmentation fault. So i left this one out.

i am now attaching the log from the garbage collector as you have suggested. i am not too sure how to read it. it contains 12 hours worth of data.
could you pls advise on what to make of it.

with regards to the new java version have not deployed as yet. However when i downloaded the JVM 1.4.2-8 it said that it is for operating system version 5.1. our system still operates on version 4.0F. My question will this have an impact?

thanks

tony

[Rick Retterer]

Hi Tony,
I don't see anything abnormal in the output log file you previously attached.

But again, this tool may have truncated the file you attached as well. I believe there is a 1mb limit on the size of files you can attach here.

Maybe try attaching the last 500 lines of the log file here.

I'm also concerned that the use of the -Xdynclassgc caused your JVM to crash. Are you using the FASTVM?

Example:

# java -version

java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition
Fast VM (build 1.4.2-7, native threads, mixed mode, 11/20/2007-11:43)

What happens if you issue this command:

# java -Xverbosegc:file:hpsupport.log -version

Does the file get created or do you get a segmentation fault?

Rick

[Rick Retterer]

In addition:

# java -Xdynclassgc -Xverbosegc:file:hpsupport.log -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition
Fast VM (build 1.4.2-7, native threads, mixed mode, 11/20/2007-11:43)

# more hpsupport.log

< garbage="" collection="" totals="">
< number="" of="" collections="" ="" 0="">
< time="" spent="" collecting="" ="" 0.00="" seconds="">
< total="">
< maximum="" heap="" size="" ="" 16.00="" mb="">

[ANTHONY CREMONA]

Hi Rick,

1) the java being used is:

/usr/opt/java142/bin/java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition
Fast VM (build 1.4.2-6, native threads, mixed mode, 01/09/2007-23:17)

2) the settings at the moment are:

java -Xverbosegc:file:hpsupport_gc.log -client -Xms64M -Xmx356M


3) I am now attaching 24 hours worth of data
from the gc log. the file is only 80KB. The file has 1386 lines in it. let me know if you get it all.

When it starts out :

GC: Garbage Collection #1 with 64.00 MB Heap (Compacting)>
< time="" since="" last="" collection="" ="" 273.22="" seconds="">
< time="" spent="" collecting="" ="" 0.17="" seconds="">
< data="" live="" before="" collection="" ="" 63.13="" mb="">
< data="" live="" after="" collection="" ="" 3.55="" mb="">
< data="" pinned="" during="" collection="" ="" 1.77="" mb="">

24 hrs later we have:


GC: Garbage Collection #231 with 260.00 MB Heap (Compacting, minor)>
< time="" since="" last="" collection="" ="" 543.50="" seconds="">
< time="" spent="" collecting="" ="" 2.13="" seconds="">
< data="" live="" before="" collection="" ="" 259.81="" mb="">
< data="" live="" after="" collection="" ="" 185.91="" mb="">
< data="" pinned="" during="" collection="" ="" 1.61="" mb="">


doesn't this mean that the HEAP size is continually expanding? we started off with 3.55MB data after collection and now we have
185.9MB data after collection.

4) when I run the following command there is no segmentation fault and the file is created.

java -Xverbosegc:file:hpsupport.log -version

5) when I run the following command there is no segmentation fault either and the file is created.


java -Xdynclassgc -Xverbosegc:file:hpsupport.log -version

6) i should add that now I am using the standby machine for testing rather than the
active production machine as I was before. The standby has the exact same hardware and software implementation.
The only difference on the standby is that there is a lot less activity, therefore much more memory available.

7) I should also add that the JMS Client all of this time, is idle. we have NOT started pumping any messages thru it. First we have to stabilise the JMS client.