[wildfly-dev] read-resource (even with include-runtime=false) iterates over dynamic children
Darran Lofthouse
darran.lofthouse at jboss.com
Mon Apr 24 13:54:02 EDT 2017
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
>
>
>
>
More information about the wildfly-dev
mailing list