My team added the "-XX:+AggressiveOpts" to the JVMs per IBM's recommendation. When the servers were started, they quickly failed. But when they restart the servers without that option, then the servers were able to start succesfully. IBM support then determined that the issue involves the HashMap class that is loaded by Foglight's agent. Here is IBM support's analysis:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thank you so much for recreating the problem with the verbose:class option. It helps us to narrow down the cause of JVM startup failure. The tracer output shows HashMap class is loaded from a different JAR file named as /apps/quest/foglight-5.5.8.2/JavaEE/5.7.2-572-20110727-2127/bootstrap/-apps-v70-services-WebSphere-AppServer-java.jar. This is passed through -Xbootclasspath option. I guess that the JAR file is provided by a 3rd party product (Foglight). To check on this, could you remove the "-apps-v70-services-WebSphere-AppServer-java.jar" from the boot classpath and then restart the JVM?
If the JVM still fails to start up without the JAR file in the boot classpath, please collect -vebose:class and startServer -trace as before. Also please let us know if there is the same problem on the other JVM such as Dmgr, Nodeagent or other Application Servers on the same box.
native_stdout.log (-verbose:class):
[Loaded java.util.HashMap from
/apps/quest/foglight-5.5.8.2/JavaEE/5.7.2-572-20110727-2127/bootstrap/
-apps-v70-services-WebSphere-AppServer-java.jar]
[Loaded java.util.HashMap$Entry from
/apps/v70/services/WebSphere/AppServer/java/jre/lib/alt-rt.jar]
Error occurred during initialization of VM
java.lang.NoSuchMethodError:
java.util.HashMap$Entry.<init>(ILjava/lang/Object;Ljava/lang/Object; Ljava/util/HashMap$Entry;)V
at java.util.HashMap.addEntry(HashMap.java:753)
at java.util.HashMap.put(HashMap.java:385)
at sun.misc.MetaIndex.regist
You need to be signed in and under a current maintenance contract to view premium knowledge articles.
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center