Bug 924903
| Summary: | JBoss AS JVM resource is not discovered after AS is restarted with jboss.platform.mbeanserver | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Operations Network | Reporter: | Larry O'Leary <loleary> |
| Component: | Plugin -- JBoss EAP 5 | Assignee: | Thomas Segismont <tsegismo> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | JON 3.1.2 | CC: | poonam_kamboj, skondkar, spinder, tsegismo |
| Target Milestone: | ER01 | ||
| Target Release: | JON 3.2.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-02 20:36:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This looks like a bug in the Mc4J component. I tracked down the issue to the EmbeddedJMXServerDiscoveryComponent.discoverResources method where the emsConnection.getBean("java.lang:type=Runtime"); call is not correctly locating the runtime components when running the 'default' profile until an agent reboot.
When this code path is executed when running the 'all' profile the runtime components are correctly retrieved without an agent restart.
The native process and commandline components are detected correctly in both cases until the evaluation by emsConnection.getBean().
Additionally it looks like we've forked the ems component (as the version used by JON is several releases later then the latest public release of MC4J) and I couldn't locate the source.
That does not seem to match my findings. In both cases of "all" and "default" profiles, emsConnection.getBean("java.lang:type=Runtime"); returns <null> on the first call. Most likely that is still a bug as the bean in both cases is actually there. However, in the case of the "all" profile we then invoke this same discovery method an additional 3 times (might be 2, can't remember) and it is the second invocation that returns what we are looking for.
Which leaves me with the following questions:
- Why does the first call in both cases return <null>? This is why the "default" profile yields no platform MBean (JBoss AS JVM) resource.
- Why does the "all" profile trigger multiple calls to discovery of the JBoss AS JVM resource type on the same parent? This too seems like a bug as we should only be performing child discovery once per service scan per parent.
(In reply to comment #1) > This looks like a bug in the Mc4J component. Do you mean the EMS component? The source is on sourceforge Setting priority to High. Fixed in master
-------------------
commit 329ac582bcf65e7c0f66ea10fd2a4faf612be2b8
Author: Thomas Segismont <tsegismo>
Date: Wed Jun 12 14:43:48 2013 +0200
Bug 924903 - JBoss AS JVM resource is not discovered after AS is restarted with jboss.platform.mbeanserver
Clear EmsConnection cache of available MBeans
-------------------
The EmsConnection used by EmbeddedJMXServerDiscoveryComponent is now refreshed before looking for the java.lang:type=Runtime MXBean (EmsConnection caches the list of MBeans it previously found).
As this is MODIFIED or ON_QA, setting milestone to ER1. Verified on JBoss ON Version: 3.2.0.ER2 Build Number: 9bf6f76:371eac0 Installed EAP 5.1 server with `default` profile. Followed the steps and verified that the JVM resource is discovered on manual autodiscovery operation on the parent platform without restarting the agent. |
Description of problem: Even though the platform MBean server is deployed and visible via jmx-console (java.lang:type=Runtime) the JBoss AS 5 plug-in fails to discover it until the agent is restarted. No errors or failure are logged. Version-Release number of selected component (if applicable): 4.4.0.JON312GA How reproducible: Always Steps to Reproduce: 1. Install EAP 5.x server with `default` profile and enable jmx-console user admin/admin. 2. Start EAP 5.x `default` profile. 3. Start ON 3.1.2 system. 4. Import EAP server into ON inventory. 5. Verify EAP is available and **DOES NOT** have a child JVM under it. 6. Shutdown EAP server and start it back up with: -Djboss.platform.mbeanserver For example: pushd "${JBOSS_EAP_HOME}/bin" && ./shutdown.sh -S -s jnp://localhost:1099 -u admin -p admin; popd; pushd "${JBOSS_EAP_HOME}" && rm -rf server/*/log && cd bin && ./run.sh -c default -b 0.0.0.0 -Djboss.platform.mbeanserver & 7. After EAP server is back up and being reported as available in ON invnetory, execute a detailed *Manual* Autodiscovery operation on the parent platform. 8. Wait for the detailed discovery to complete. Actual results: No JBoss AS JVM resource will appear under the JBoss AS resource until the ON agent is restarted. Expected results: JBoss AS JVM resource appears under the JBoss AS resource. Additional info: This issue is profile specific. If you use the `all` profile from an EAP installation using the above steps, you get the "expected" behavior. I have set the severity to high because it appears discovery in general is drastically different within the two profiles. There appears to be quite a bit of duplication and recursion of discovery when using the `all` profile as opposed to the `default` profile. Obviously we expect more services to be discovered but I am not sure why the `all` profile triggers the same services to be discovered multiple times. This issue may impact quite a bit more then the JBoss AS JVM resource.