Bug 924903 - JBoss AS JVM resource is not discovered after AS is restarted with jboss.platform.mbeanserver
Summary: JBoss AS JVM resource is not discovered after AS is restarted with jboss.plat...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- JBoss EAP 5
Version: JON 3.1.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ER01
: JON 3.2.0
Assignee: Thomas Segismont
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-22 19:14 UTC by Larry O'Leary
Modified: 2018-11-30 19:19 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-01-02 20:36:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 333703 0 None None None Never

Description Larry O'Leary 2013-03-22 19:14:59 UTC
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.

Comment 1 Simeon Pinder 2013-04-03 00:15:30 UTC
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.

Comment 2 Larry O'Leary 2013-04-03 13:33:25 UTC
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.

Comment 3 Charles Crouch 2013-04-09 15:58:28 UTC
(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

Comment 4 Charles Crouch 2013-04-09 15:59:55 UTC
Setting priority to High.

Comment 5 Thomas Segismont 2013-06-12 12:59:14 UTC
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).

Comment 6 Larry O'Leary 2013-09-06 14:33:38 UTC
As this is MODIFIED or ON_QA, setting milestone to ER1.

Comment 7 Sunil Kondkar 2013-09-30 11:43:37 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.