[wildfly-dev] read-resource (even with include-runtime=false) iterates over dynamic children
Brian Stansberry
brian.stansberry at redhat.com
Mon Apr 24 15:36:48 EDT 2017
I agree.
The kernel can be better about the JMX stuff I think, but some cases like MBeanServer.getMBeanCount() mean there’s no alternative to identifying every resource. But for some less extreme cases we can be better I think by avoiding the unknown-cost runtime-only resources and just dealing with the known-cost ManagementResourceRegistration data. I filed a JIRA for that:
https://issues.jboss.org/browse/WFCORE-2719
> On Apr 24, 2017, at 1:20 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>
> +1, in consideration of all the facts this seems like a better approach.
>
> On 04/24/2017 12:54 PM, Darran Lofthouse wrote:
>> Moving away from resources to operations may make more sense -
>> especially for realms with large a number of identities.
>>
>> On 24/04/17 18:44, Jan Kalina wrote:
>>> Darran, when consider mentioned problems (especially getting amount of
>>> all mbeans and other operations
>>> on mbeans, where we cannot filter runtime only things out) do we have
>>> same reason to represent identities as resources?
>>> (Using realm operations instead sounds reasonable.)
>>>
>>> On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry
>>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>>>
>>> Here’s my last post again. For some reason my mail client decide to
>>> encrypt it when it resent it.
>>>
>>>> On Apr 23, 2017, at 7:31 AM, Brian Stansberry
>>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>> wrote:
>>>>
>>>>> On Apr 21, 2017, at 2:22 AM, Jan Kalina <jkalina at redhat.com
>>> <mailto:jkalina at redhat.com>> wrote:
>>>>>
>>>>> Not sure if it helps for JMX, but at least for management I see
>>> the core of the problem in obtaining
>>>>> children of node even through there is placeholder pushed into
>>> the operation result...
>>>>> It is something for which I dont see any reason - this should be
>>> possible to fix even without management behaviour change.
>>>>>
>>>>
>>>> There is a placeholder per address. Even if we made the
>>> placeholder objects go away, we have a requirement to list the child
>>> addresses that cannot be made to go away. The critical cost here is
>>> identifying those addresses, more so than manipulating the
>>> placeholder objects. Identifying those addresses means making a
>>> remote call to an LDAP server and iterating over possibly thousands
>>> of results.
>>>>
>>>>> Not experienced in JMX, but are not the same placeholders used
>>> here too? (if yes, it could be the same problem…)
>>>>>
>>>>
>>>> If we say an identity is a management resource, that means we can
>>> produce an mbean for it. And that means JMX ops like
>>> MBeanServer.getMBeanCount() need to access all of those resources,
>>> at a minimum to know their address.
>>>>
>>>> Why do these identities need to be represented as management
>>> resources?
>>>>
>>>>>
>>>>> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry
>>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>> wrote:
>>>>>
>>>>>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry
>>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>> wrote:
>>>>>>
>>>>>> I know that internally it’s useful in a number of places to know
>>> what children a resource has even without knowing their details
>>> beyond their address. If it’s useful internally it seems like it
>>> could be useful to outside callers too. I don’t know if HAL uses it.
>>>>>>
>>>>>> Removing that data would be a breaking change in our responses.
>>> Perhaps we could consider it for the
>>> :read-resource(include-runtime=false) case since the user has
>>> explicitly said they want things excluded, but for non-recursive
>>> :read-resource() (i.e. include-runtime=true) that would be a bigger
>>> problem with no way for users to get the data without using
>>> recursive=true.
>>>>>>
>>>>>> Regardless of that, having management resources represent remote
>>> objects is problematic for JMX. All management resources, dynamic or
>>> not, are available via JMX. MBeanServerConnection.getMBeanCount()
>>> and various uses of queryNames and queryMBeans with ObjectName
>>> patterns as the param result in needing to access all these
>>> resources. I can’t find any JMX API that would make it easy for
>>> users to say “except the runtime-only ones” plus I think some users
>>> wouldn’t be interested in that kind of thing anyway. I’ve heard of
>>> general purpose agent tools that do this kind of thing.
>>>>>>
>>>>>> One thought I had as I wrote this is perhaps marking the
>>> resources as remote may help. I don’t believe we expose remote
>>> resources via JMX, and if we do that sounds like a bug. Up to now,
>>> ‘remote’ has been used for the resource for other WF processes in a
>>> managed domain, but perhaps the use of the concept could be expanded.
>>>>>>
>>>>>> So, we should look into ‘remote’ and maybe all this goes away. :)
>>>>>
>>>>> I poked a bit and while this may be an interesting thing to
>>> explore some day it’s not something practical for WF 11. The
>>> handling of ‘remote’ resource types is based on their being no
>>> Resource instances for them in the local resource tree, and then a
>>> special ManagementResourceRegistration is registered for each
>>> individual resource (/host=slave, /server=server-one etc) that
>>> proxies any operations addressed to that specific resource to a
>>> remote WildFly process. It’s not something applicable to other sorts
>>> of usage.
>>>>>
>>>>>>
>>>>>> If that doesnt’ pan out, I question why these things need to be
>>> modeled as resources. AFAICT they have no attributes and are just
>>> addresses against which operations can be executed. I don’t see much
>>> benefit in:
>>>>>>
>>>>>>
>>> /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity
>>>>>>
>>>>>> vs
>>>>>>
>>>>>> /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)
>>>>>>
>>>>>> or
>>>>>>
>>>>>>
>>> /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:add(foo=bar,xyz=true)
>>>>>>
>>>>>> vs
>>>>>>
>>>>>>
>>> /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=ldapUser,foo=bar,xyz=true)
>>>>>>
>>>>>> Modeling these as resources allows you to list the identities
>>> etc via things like read-resource, read-children-names, etc but
>>> that’s both a feature and a bug. ;) A list-identities op on the
>>> realm accomplishes much the same thing.
>>>>>>
>>>>>>
>>>>>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com
>>> <mailto:jkalina at redhat.com>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>> I am just checking how wildfly controller handle dynamic
>>> resources because
>>>>>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>>>>>>> include-runtime=false) asks parent resource for list of all
>>> dynamic (runtime only)
>>>>>>> children.
>>>>>>>
>>>>>>> For example query:
>>>>>>>
>>> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>>>>>>> will cause "server" resource (child of messaging-activemq) is
>>> asked for list
>>>>>>> of all "core-address" (call getChildren("core-address")), even
>>> trough they are not
>>>>>>> displayed as part of operation result - only blank placeholder
>>> is printed:
>>>>>>> "core-address" => undefined,
>>>>>>>
>>>>>>> This is problem especially in case of new Elytron resources
>>> which allow to browse
>>>>>>> user identities using AS model - every :read-resource on root
>>> or every AS boot
>>>>>>> currently causes iterating over all users/identities available
>>> in all concerned realms.
>>>>>>>
>>>>>>> Is this design problem?
>>>>>>> Is there some reason why should wildfly controller ask for all
>>> resource children
>>>>>>> even when they are ignored and not printed?
>>>>>>> What do you think about it? How should be resources with
>>> dynamic children handled?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Honza
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Manager, Senior Principal Software Engineer
>>>>>> JBoss by Red Hat
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> JBoss by Red Hat
>>>
>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list