10:35 a.m.
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 <https://github.com/hpehl/map-reduce>
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info
11:03 a.m.
Taken to its logical conclusion, this would become a full-fledged query
language.
You could just create a client-side library for it and use that as the
"language" develops. I think that would be a safe thing to do before
committing it as part of the supported server side interface.
How much of a problem would this be if it were not for GWT's
callback-hell? It's my understanding that GWT is fixing that?
On 10/31/2014 11: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
11:05 a.m.
Am 31.10.2014 um 17:03 schrieb Stan Silvert
<ssilvert(a)redhat.com>:
How much of a problem would this be if it were not for GWT's callback-hell?
It's my understanding that GWT is fixing that?
HAL is not the only client out there that needs that.
RHQ/JBoss ON can heavily benefit from that.
1:46 p.m.
The problem has nothing todo with GWT.
The single purpose of Haralds proposal is to reduce the number of requests and the actual
amount of data when querying large groups of servers. The native interface suffer from
this as well, it's just not that obvious because it's per se more performant then
the HTTP interface (optimised wire format, persistent connections, etc).
On 31 Oct 2014, at 17:05, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
> Am 31.10.2014 um 17:03 schrieb Stan Silvert <ssilvert(a)redhat.com>:
> How much of a problem would this be if it were not for GWT's callback-hell?
It's my understanding that GWT is fixing that?
HAL is not the only client out there that needs that.
RHQ/JBoss ON can heavily benefit from that.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:35 p.m.
On 10/31/2014 2:46 PM, Heiko Braun wrote:
The problem has nothing todo with GWT.
It has everything to do
with GWT. The client code to deal with his
problem is 10x simpler in real Java. I know because I've coded both
many times.
The single purpose of Haralds proposal is to reduce the number of requests and the actual
amount of data when querying large groups of servers. The native interface suffer from
this as well, it's just not that obvious because it's per se more performant then
the HTTP interface (optimised wire format, persistent connections, etc).
That's
not true. Management requests are small, fast, and cheap. Doing
it over HTTP makes no noticeable difference.
The good thing about Harald's proposal is that it would make the code a
little simpler for Java clients and a lot simpler for GWT clients.
On 31 Oct 2014, at 17:05, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
>> Am 31.10.2014 um 17:03 schrieb Stan Silvert <ssilvert(a)redhat.com>:
>> How much of a problem would this be if it were not for GWT's callback-hell?
It's my understanding that GWT is fixing that?
> HAL is not the only client out there that needs that.
> RHQ/JBoss ON can heavily benefit from that.
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:18 p.m.
Am 31.10.2014 um 20:35 schrieb Stan Silvert
<ssilvert(a)redhat.com>:
On 10/31/2014 2:46 PM, Heiko Braun wrote:
> The problem has nothing todo with GWT.
It has everything to do with GWT. The client code to deal with his
problem is 10x simpler in real Java. I know because I've coded both
many times.
>
> The single purpose of Haralds proposal is to reduce the number of requests and the
actual amount of data when querying large groups of servers. The native interface suffer
from this as well, it's just not that obvious because it's per se more performant
then the HTTP interface (optimised wire format, persistent connections, etc).
That's not true. Management requests are small, fast, and cheap. Doing
it over HTTP makes no noticeable difference.
The good thing about Harald's proposal is that it would make the code a
little simpler for Java clients and a lot simpler for GWT clients.
It's really about making management operations for big domains easier and more
performant. The current proposal is not meant to be a used as a query language. It's
purpose is clearly focused to read resources / attributes over deeply nested or
distributed resources.
Whether the client is using GWT or any other language or framework is not the main focus
of the proposal. It just happens to fit quite well to GWT's asynchronous nature.
>
>
> On 31 Oct 2014, at 17:05, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
>
>>> Am 31.10.2014 um 17:03 schrieb Stan Silvert <ssilvert(a)redhat.com>:
>>> How much of a problem would this be if it were not for GWT's
callback-hell? It's my understanding that GWT is fixing that?
>> HAL is not the only client out there that needs that.
>> RHQ/JBoss ON can heavily benefit from that.
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info
1:40 p.m.
Haralds proposal was designed to be orthogonal to the concepts we currently have and embed
within existing protocols and API. The idea is to build something straightforward to solve
real problems.
A query language sounds nice, but I don't really see how it relates to problems
described in the former proposal. If you want to discuss that idea further, I would
suggest to move it to another thread.
On 31 Oct 2014, at 17:03, Stan Silvert <ssilvert(a)redhat.com> wrote:
Taken to its logical conclusion, this would become a full-fledged
query language.
You could just create a client-side library for it and use that as the
"language" develops. I think that would be a safe thing to do before committing
it as part of the supported server side interface.
How much of a problem would this be if it were not for GWT's callback-hell?
It's my understanding that GWT is fixing that?
2:16 p.m.
On 10/31/2014 2:40 PM, Heiko Braun wrote:
Haralds proposal was designed to be orthogonal to the concepts we
currently have and embed within existing protocols and API. The idea
is to build something straightforward to solve real problems.
A query language sounds nice, but I don't really see how it relates to
problems described in the former proposal. If you want to discuss that
idea further, I would suggest to move it to another thread.
A lot of your
particular problem is with GWT, and that is indeed a topic
for another thread.
Herald's proposal is a good one and people would want to do more with it
than just solve your particular dilemma. Thus, it eventually becomes
more and more like a query language.
My point was just that if Herald is interested, he could easily do this
on the client side and move it to the server side after it matures.
But if Brian wants to plow ahead on the server side that's good too.
On 31 Oct 2014, at 17:03, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
> Taken to its logical conclusion, this would become a full-fledged
> query language.
>
> You could just create a client-side library for it and use that as
> the "language" develops. I think that would be a safe thing to do
> before committing it as part of the supported server side interface.
>
> How much of a problem would this be if it were not for GWT's
> callback-hell? It's my understanding that GWT is fixing that?
11:05 a.m.
Am 31.10.2014 um 16:35 schrieb Harald Pehl <hpehl(a)redhat.com>:
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
Awesome, go for it.
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
1:30 p.m.
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
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:05 p.m.
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
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:01 p.m.
Ok, let's discuss it further. Maybe on irc. I dont fully understand your use case, but
if you explain it further i am confident we can contribute to it.
Am 31.10.2014 um 20:05 schrieb Brian Stansberry
<brian.stansberry(a)redhat.com>:
> 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
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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:25 p.m.
Great. Chatting on IRC will be fine. We should involve Emanuel
Muckenhuber, as he did the single-process wildcard read support we have,
and he likely remembers best the hassles in doing it across processes.
The use case is basically the same one Harald has -- trying to get a
bunch of data in one request. Harald goes further by filtering out
addresses and/or attributes, but it all starts with sucking in lots of data.
On 11/3/14, 12:01 PM, Heiko Braun wrote:
Ok, let's discuss it further. Maybe on irc. I dont fully understand your use case,
but if you explain it further i am confident we can contribute to it.
> Am 31.10.2014 um 20:05 schrieb Brian Stansberry <brian.stansberry(a)redhat.com>:
>
>> 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 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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
4:33 p.m.
Am 31.10.2014 um 18:07 schrieb Brian Stansberry
<brian.stansberry(a)redhat.com>:
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.
I agree. The map / reduce name was kind of a working title. Any better terms are welcome!
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info
3671
days inactive
3674
days old
14 comments
5 participants
participants (5)
-
Brian Stansberry -
Harald Pehl -
Heiko Braun -
Heiko W.Rupp -
Stan Silvert