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
RESOLUTION:
Bootstrap jar is created for the jdk they are using…so those classes come from the jdk not from us.
Perhaps you need to pass the AggressiveOpts option while creating the bootstrap jar as well…In the setupcmdline.sh/cmd script just before the call to integrate.cmd, we can insert a variable called QUEST_PREINST_OPTS and pass the AggressiveOpts option to it. So the preinstrumentor will also get created with that option.
Verify it with the resulting preinstrumentor jar file.
And then see if you have the issue while starting up the server.
WORKAROUND:
try the below
1. Go to directory <Java EE agent home>/config/agent
2. Copy instrumentation.config to <Java EE agent home>/config/agent-override
3. Make the following change to agent-override/instrumentation.config.
4. Search for InstrumentedClasses within the file and commenting out these from instrumentation.config file
e.g.
ObjectTrackerClasses = {
# include "java.util.AbstractCollection",
# include "java.util.AbstractMap",
# include "java.util.ArrayList",
# include "java.util.HashMap",
# include "java.util.HashSet",
# include "java.util.LinkedList",
# include "java.util.TreeMap",
# include "java.util.TreeSet",
),
5. Restart the appserver
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center