[wildfly-dev] Map / reduce for management operations

Brian Stansberry brian.stansberry at redhat.com
Fri Oct 31 15:05:11 EDT 2014


On 10/31/14, 1:30 PM, Heiko Braun wrote:
>
> On 31 Oct 2014, at 18:07, Brian Stansberry <brian.stansberry at 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 expectations.
>
>> 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:
>>> TL;DR
>>>
>>> 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
>>> servers.
>>>
>>> # Proposal / Prototype
>>>
>>> The GitHub repository at [1] 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.
>>>
>>> [1] https://github.com/hpehl/map-reduce
>>>
>>> ---
>>> Harald Pehl
>>> JBoss by Red Hat
>>> http://hpehl.info
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> 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
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list