12:07 p.m.
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.
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. 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat