[wildfly-dev] read-resource (even with include-runtime=false) iterates over dynamic children
David M. Lloyd
david.lloyd at redhat.com
Mon Apr 24 14:20:55 EDT 2017
+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
More information about the wildfly-dev
mailing list