Zorka compatibility with SDK 1.7 (Websphere)
Mehdi Nakkouch
Hi everyone,
We are actually using Zabbix with Zorka agents for monitoring our Webphere servers, and we made a technical upgrade by setup the version of the SKD from 1.6 to 1.7. This operation caused a compatibility problem with the Zorka agent and it blocks the startup of the JVM nodes on WebSphere, so we had to suspend the agent (by removing this argument from the JVM "javaagent:/opt/IBM/WebSphere/AppServer/profiles/AppSrvUI01/servers/ServerUI1/zorka/zorka.jar=/opt/IBM/WebSphere/AppServer/profiles/AppSrvUI01/servers/ServerUI1/zorka" in order to start the servers.
When we try to start them, we catch this error:
WSVR0100W: Initialising error, ServerUI1 [class com.ibm.ws.runtime.component.ServerImpl]
java.lang.VerifyError: JVMVRFY012 forme de la pile incohérente; classe=com/ibm/ws/classloader/ProtectionClassLoader, méthode=(Ljava/lang/ClassLoader;)V, pc=0
at com.ibm.ws.runtime.component.ServerImpl.initialize(ServerImpl.java:343)
at com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:293)
at com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:224)
at com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:697)
at com.ibm.ws.runtime.WsServer.main(WsServer.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at com.ibm.wsspi.bootstrap.WSLauncher.launchMain(WSLauncher.java:234)
at com.ibm.wsspi.bootstrap.WSLauncher.main(WSLauncher.java:96)
at com.ibm.wsspi.bootstrap.WSLauncher.run(WSLauncher.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:340)
at org.eclipse.core.launcher.Main.basicRun(Main.java:282)
at org.eclipse.core.launcher.Main.run(Main.java:981)
at com.ibm.wsspi.bootstrap.WSPreLauncher.launchEclipse(WSPreLauncher.java:398)
at com.ibm.wsspi.bootstrap.WSPreLauncher.main(WSPreLauncher.java:161)
So we tried differents solutions:
- Setup the last stable version of Zorka 1.0.16
- Setup the development version 1.90.1
- Modify Websphere parameters by desactivating Xverify and Xshareclasses
We identified that these scripts in the source code "WAS.BSH" were the origin of the problem :
_spy.add(spy.instance("WAS_MBS_REGISTER")
.onReturn(spy.fetchArg("THIS", 0), jvm.autoregister_plugin(), pmi_register())
.include(spy.byMethod("com.ibm.ws.management.AdminServiceImpl", "")));
spy.add(spy.instance("WAS_CATCH_CLASS_LOADER")
.onReturn(spy.fetchArg("THIS", 0), class_loader_catcher())
.include(spy.byMethod("com.ibm.ws.classloader.ProtectionClassLoader", "")));_
We put them in comment. This is the only solution that worked but we don't know the usefulness of these scripts. Do you thinkk that we can continue working without them?
As we are constrained to Upgrade our SDK version as part of our project, we would like to find a solution with this parameter.
Please, if you have any suggestion about this problem or a confirmation about the shared scripts, let us know, we would be thankful.
Best regards,
Mehdi NAKKOUCH
