Join GitHub today
How to implement compatibility of the Jolokia JVM agent with org.jboss.logmanager.LogManager loaded form JBoss modules #258
Currently we have enabled the Jolokia JVM agent with JBoss EAP 6.0.x & 6.2.x.
To get the JVM Agent running, we have added the
This is currently the official workaround described by RedHat: https://access.redhat.com/solutions/312453
Alos other JVM agents have the same problem: https://issues.jboss.org/browse/WFLY-895
But in JBoss EAP 6.4. this is no more working:
Even when you add the system property
This exception is caused by changed class loading behaviour in JBoss eap 6.4. It looks like the
In my option it was never a clean solution to override classes loaded by JBoss modules via the system class loader (
I have to find a solution for already released version of JBoss eap (6.2.2, 6.4.1, 6.4.7).
Implement a solution for the problem in products is not easy
I agree with you suggestion that a solution within the product (e.g. swarm ) would be nice, but it is not that simple, as the
The Jolokia JVM agent should be running fine in environments where the
You have already thought how to solve this in a clean and portable approach: https://issues.jboss.org/browse/SWARM-204
Option 1 is not solving the issue as the issue in EAP 6.4 is triggered by the too early loading.
I have some additional options:
Option 5 has a small runtime impact, and is most likely too confusing/magic for maintainers & users.
IMO a solution of option 2 is the way to go.
Proposal for option 2
Here a proposal to implement option 2:
To check if a class has been loaded, I propose to poll Instrumentation.getAllLoadedClasses
The steps 3-6 are needed for the case in which JBoss (or any other component) has configured the system property an loaded the class but the LogManager is not jet initialized.
In the case of JBoss, the steps 3-6 are required if:
To get an instance of Instrumentation, the JVM agent needs to be implemented with the following signature:
I think the solution should not introduce time outs as this will complicate the implementation. I think logging the most important steps should be enough.
What do you think about this proposal for the option 2?
@rraez thanks for coming back to this (annoying ;-) issue. Lets fix it now :)
To your additional suggestions:
I guess this would mean to include an extra dependency (asm, another http-server) which I'm not keen on. Jolokia was designed with the constraint to be as small as possible in order to minimize impact. The only dependency is on json-simple (23k), not even logging.
You suggestion around option (2) sounds feasible. Do you think there could be a way to detect early and quickly whether running in an Wildfly environment so that we could set the suggested option
The reason I ask is because its really only the Wildfly platform which has this issue, not one of the other 30+ platform in my integration test suite (including the former JBoss AS servers) has a similar problem. I had different issues on different platform (e.g. for detecting the MBeanServer on Weblogic is also not trivial), so use server detection like the JBossServerDetector to cope with platform peculiarities. It would be cool if we could include our workaround into this facility, too, but I'm afraid the detector stuff kicks in too late. To sacrifice an option (of which I already have too many I'm afraid) should be the last resort.
Said that I would happily integrate a PR or even the vanilla detection code if you have POC.
Thanks again for you investigating this tricky thing.
Thanks for you quick response. I definitely agree to keep the dependencies as minimal as possible, this is a key strength of Jolokia.
I like your idea, I will think about the automatic detection of JBoss module based JEE platforms (Wildfily, JBoss EAP 6+). This detection must not kick off just in case some JBoss libraries are on the class path. JBoss modules is used not only for the appserver, e.g. it is used to implement modules in the ceylon language.
added a commit
May 20, 2016
referenced this issue
May 25, 2016
added a commit
Oct 12, 2016
Finally I'm about to integrate this fix into Jolokia (although I think swarm would be the more appropriate place).
The final missing piece is how to detect whether running und wildfly-swarm, which must be available early on.
The current algorithm checks two things:
It would be awesome if someone could either verify that this is necessary and sufficient, or if otherwise please update this issue with a unique way to identify swarm. Also it would be awesome if Swarm could be detected to extract its version number so that Jolokia can expose this to the outside (and while we are here also, how to differentiate between Wildfly AS and wildfly-swarm since this detector is used for both platforms)
We have migrated several (slightly complex) EE applications to Swarm and have seen that the Swarm detection of Jolokia in agent mode is likely sensitive to timing issues. In ca. 20% of application restarts the detection fails, and we get the same exception as in the original description. I tried to reproduce it with a toy application, but was able to do so up too now.