This content has been marked as final. Show 4 replies
This has a lot to do with the Garbage handling mechanism in every JVM that you are using.
Oracle has provided slightly different ways to collect the garbage and free up memory with versions of JVM the following link would help you on that.
JDK 1.6 Adoption
So with a close look to the above urls you can reconfigure your runtime environments to handle this error.
Revert for more clarifications.
984172 wrote:So your production environment runs on exactly the same hardware as the UAT? And with the same patching?
After some changes in the code and many test in UAT environment(which is the same with production)
I cannot replicate the error in UAT.Set the maximum heap size. Run your test. If it does not fail reduce the maximum until it does. It WILL fail at some point. At that point you can determine if the failure is reasonable (the result of a bug) or unreasonable (just too small). If the later then you should look at your stress test to verify that what it tests actually looks like realistic production traffic.
The only different in the new version is that we had some changes in the code and we compile in java 1.5 using jre6 for jboss and for tomcat compile in java 1.5 using jdk1.6.You can't compile with a JRE, so there is already something wrong with this statement, and I don't understand where jrockit comes into it, but obviously the first place to look for this problem is the new code. I don't know why you think using a different compiler would affect garbage collection and/or memory usage. It seems a pretty remote possibility to me.
@PranavS You are going to have to explain to us how different GC strategies can cause OutOfMemoryErrors. That only happens when everything possible has been garbage collected and the amount of new heap memory requested still isn't available. Strategy has nothing to do with it.