[jboss-jira] [JBoss JIRA] (WFCORE-2719) Better use the ManagementResourceRegistration data in JMX query handling

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2719:
-------------------------------------
    Description: 
For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.

Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}

No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.

Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.


  was:
For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.

Imagine a query for 

jboss.*:j2eetype=*,*

or, less extreme:

jboss.as:socket-binding=*,*

No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.

Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.




> Better use the ManagementResourceRegistration data in JMX query handling
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-2719
>                 URL: https://issues.jboss.org/browse/WFCORE-2719
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, JMX
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
> Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}
> No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.
> Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)