[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