Zorka apparently conflicts with WAR class loader policy about zorka HOT 7 CLOSED

Hello,

Can you send me zorka.properties file (without password of course) ?

You can also try disabling all subsystem of agent: spy, tracer, mbean registration etc. and see if "dormant" agent still breaks WAS (I'll try it myself as from your description this bug should be repeatable).

Regards,
rle

from zorka.

Hi!

Here the relevant entries in zorka.properties:

# grep -v '^$\|^#' zorka.properties 
scripts = jvm.bsh, zabbix.bsh, ibm/was.bsh
was.user = zabbix
was.pass = secret
zabbix.server.addr = 127.0.0.1,zabbix.example.com
zabbix.listen.port = 10055
tracer = no

As soon as we have identified which options have to be set in zorka.properties to disable all subsystems we'll give it another try. After this I'll report again.

Thanks in advance!

from zorka.

Options to disable everything AFAIR:

spy = no
zabbix = no
nagios = no

And comment out scripts line (or leave it empty AFAIR, so it will not load any BSH scripts).

Then check agent log if there are errors (or more logs about something starting up etc.).

I hope it is all, maybe I'll check it out later and describe somewhere in documentation.

Regards,
rle

from zorka.

So, just got the result from the admin.
This issue exists only when ibm/was.bsh is configured.

from zorka.

Ok, this tells me a lot. So now one thing to check is was.bsh script - if you have time for it.

Please extract was.bsh from zorka.jar: com/jitlogic/zorka/scripts/ibm/was.bsh.

Create directory scripts in agent home directory, create directory ibm inside scripts and copy 'was.bsh' file to 'ibm' directory.

Edit was.bsh file and find two sections:

  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", "<init>")));

and

  spy.add(spy.instance("WAS_CATCH_CLASS_LOADER")
    .onReturn(spy.fetchArg("THIS", 0), class_loader_catcher())
    .include(spy.byMethod("com.ibm.ws.classloader.ProtectionClassLoader", "<init>")));

Try comment each one of those sections (separately) and tell me which one (if any) causes problem.

I'll try configuring may own environment and replicating this problem but it might take some time due to significant backlog of various tasks I have to do next week.

from zorka.

Sorry for the delay!

We made the requested test today and even commenting both sections didn't help.
Please don't hesitate to ask for any test that might support finding the cause.

from zorka.

I've fixed a nasty bug regarding JDK7/8 and stack maps calculation some time ago. It was causing spurious class loads from time to time that were bypassing instrumentation (and possibly violating custom class loader policies). It was appearing in various contexts especially with JDK8, I suppose it was the cause of this issue. I'm closing this, if you still have problems please reopen.

from zorka.