Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-2719

Better use of the ManagementResourceRegistration data in JMX query handling

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Unresolved
    • Major
    • None
    • None
    • JMX, Management
    • None

    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

      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. (Remember, the key/value pairs in an ObjectName are not required to be in a particular order so we can't assume the order matches the order of key/value pairs in a PathAddress. So we'd have to look for any resource with an address with a PathElement at any position whose key is 'j2eetype' or 'socket-binding'.)

      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 on those parts of the tree where a Resource search is necessary.

      Attachments

        Activity

          People

            Unassigned Unassigned
            bstansbe@redhat.com Brian Stansberry
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: