[jboss-jira] [JBoss JIRA] (WFCORE-3415) Cut the time to execute MBeanServerConnection.getMBeanCount()

Cut the time to execute MBeanServerConnection.getMBeanCount() ------------------------------------------------------------- Key: WFCORE-3415 URL: https://issues.jboss.org/browse/WFCORE-3415 Project: WildFly Core Issue Type: Enhancement Components: JMX Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 4.0.0.Alpha3 The time it takes to count the mbeans associated with the jboss.as and jboss.as.expr domains is way too high, over a full second when the WildFly full standalone-full-ha.xml config is used, and potentially much higher if complex deployments are installed. See WFLY-9408. This enhancement proposes doing two things to mitigate this: 1) There is no point doing a full count of both jboss.as and jboss.as.expr as they are just 2 views on the same underlying resources. If both are present, count one and double it. 2) Do not use RBAC to exclude from the count mbeans the user won't be allowed to see. They exist whether the user can see them or not. Simply count the resources. Looking at the JMX specification (https://docs.oracle.com/javase/8/docs/technotes/guides/jmx/JMX_1_4_specif...) I see nothing directly on the topic of the effect of any security checks on the result of getMBeanCount(). Section 12.1.2.4 "Permission Checking for Queries" clearly states that permission checks should remove mbeans that should not be visible according to the permission scheme from the query result, so definitely queries returning a subset of the entire mbean universe is contemplated. Now, that section is about security manager permissions, not our RBAC scheme, but it's the most on topic thing I see. Doing these two things I can get the cost of a getMBeanCount() from around 1 second to under 10 ms. (Note the 1 sec figure is the first call; once the JVM optimizes the existing code it drops to under 500ms.) The enhancement will also make it possible for custom Resource implementations to optimize things. For example a resource that represents a possibly large number of dynamic children could ask the system behind those children for a child count, rather that iterating over the children.