On 31 Oct 2014, at 18:07, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
This would definitely be useful.
On the server side we already support a wildcard variant of
read-resource. But it only works within a single process, not across
processes in the domain. We've never had time to sort that issue. I'd
like to see this feature built on a foundation of a proper cross-domain
wildcard read-resource. That will kill two birds with one stone, plus
ensure consistent behavior.
glad to hear. we specifically isolated it from the current codebase to explore the ideas,
before merging with existing approaches. Bringing it into the main codebase would be a
task for somebody with a better understanding of the management layer internals.
Any other ideas for a name for this? "Map / reduce" to me implies a much
broader set of functionality, and I wouldn't want to falsely advertise,
nor burn an operation name that we may want later.
the name describes quiet well what's actually happening behind the scenes, but I agree
that "map/reduce" is quiet overloaded these days and might lead to false
That also relates to
Stan's point in his response, re: this being an element in a broader
query feature. If it has a precise name that implies a narrow scope, if
later on there is a broader feature that broader feature can co-exist
with its ancestor.
On 10/31/14, 10:35 AM, Harald Pehl wrote:
> For management clients it is tedious and awkward to read resources /
> attributes in big domains (e.g. return the state of all running servers
> across all hosts which are part of server group "foo"). Today this
> requires to setup multiple composite operations *on the client* which
> need to be executed in a specific order. This proposal suggests a new
> operation which collects all relevant information *on the
> server* and returns only the relevant data in one go to the client.
> # Background:
> In the admin console we often need to read specific attributes across a
> domain or across a deeply nested resource:
> - List all enabled data sources of the current profile
> - Show the port offset of all running servers across all hosts
> - Get all users which belong to role Operator
> Even for small domains with two server groups and a small number of
> servers this procedure is awkward and error prone. What makes it even
> more difficult is the asynchronous nature of the admin console. Soon you
> end up in a deeply nested callback-hell. Besides that these 'queries'
> lead to poor performance for big domains with tens of groups, hosts and
> # Proposal / Prototype
> The GitHub repository at  contains a more detailed description of the
> problem statement and a working prototype. This includes details such as
> how to address the requested resources, how the information is retrieved
> and how to handle errors.
> The proposal also includes a way to filter and reduce the resources
> against a list of attributes and values *before* the response is sent to
> the client.
>  https://github.com/hpehl/map-reduce
> Harald Pehl
> JBoss by Red Hat
> wildfly-dev mailing list
Senior Principal Software Engineer
JBoss by Red Hat
wildfly-dev mailing list