On 10/31/14, 1:30 PM, Heiko Braun wrote:
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.
Oh. I can't commit to when we'd be able to do multi-process wildcard
read-resource. I was fired up by the possibility that a talented guy
like Harald was interested. :) This thread certainly raises the
visibility of it though. I'll be thinking about how to do it.
> 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
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> wildfly-dev mailing list
Senior Principal Software Engineer
JBoss by Red Hat