2:20 p.m.
Here's the use case: a monitoring app wants to monitor a WildFly instance - it will
ask WildFly for the values of N attributes across M resources in one bulk composite
request. This would avoid having to send one request for each individual attribute being
collected (rather than one request for all of them at once).
Is there a way I can configure a composite request such that WildFly will not abort the
entire composite request if a single step to read an attribute fails?
For example, suppose I send this - I'm basically asking Wildfly "tell me the
status of my two deployed applications a.war and b.war" :
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "read-attribute",
"address" => [("deployment" => "a.war")],
"include-runtime" => false,
"name" => "status"
},
{
"operation" => "read-attribute",
"address" => [("deployment" => "b.war")],
"include-runtime" => false,
"name" => "status"
}
]
}
Well, if someone undeployed a.war, that first step results in an error, but it also
completely aborts the composite operation so I can't find the status of b.war either,
unless a.war exists.
I would like composites like this to tell me the status of every read-attribute - whether
a failure or not. If not possible, I'm forced to split this up and make two individual
requests for each attribute.
Extrapolate that out - if I have N attributes I want to collect at the same time, I would
be forced to make N individual requests rather than 1 composite request just to avoid the
case where if one of them failed, I would lose the data for all N.
2:30 p.m.
FWIW: this is what the response would look like in my example if a.war was undeployed:
{
"outcome" => "failed",
"result" => {
"step-1" => {
"outcome" => "failed",
"failure-description" => "JBAS014807: Management resource
'[(\"deployment\" => \"a.war\")]' not found",
"rolled-back" => true
},
"step-2" => {"outcome" => undefined}
},
"failure-description" => {"JBAS014653: Composite operation failed
and was rolled back. Steps that failed:" => {"Operation step-1" =>
"JBAS014807: Management resource '[(\"deployment\" =>
\"a.war\")]' not found"}},
"rolled-back" => true
}
----- Original Message -----
Here's the use case: a monitoring app wants to monitor a WildFly
instance -
it will ask WildFly for the values of N attributes across M resources in one
bulk composite request. This would avoid having to send one request for each
individual attribute being collected (rather than one request for all of
them at once).
Is there a way I can configure a composite request such that WildFly will not
abort the entire composite request if a single step to read an attribute
fails?
For example, suppose I send this - I'm basically asking Wildfly "tell me the
status of my two deployed applications a.war and b.war" :
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "read-attribute",
"address" => [("deployment" =>
"a.war")],
"include-runtime" => false,
"name" => "status"
},
{
"operation" => "read-attribute",
"address" => [("deployment" =>
"b.war")],
"include-runtime" => false,
"name" => "status"
}
]
}
Well, if someone undeployed a.war, that first step results in an error, but
it also completely aborts the composite operation so I can't find the status
of b.war either, unless a.war exists.
I would like composites like this to tell me the status of every
read-attribute - whether a failure or not. If not possible, I'm forced to
split this up and make two individual requests for each attribute.
Extrapolate that out - if I have N attributes I want to collect at the same
time, I would be forced to make N individual requests rather than 1
composite request just to avoid the case where if one of them failed, I
would lose the data for all N.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:11 p.m.
Try this:
/deployment=*:read-attribute(name=status,include-runtime=true)
The composite op won't allow you to tell it ignore failures in reading
the configuration model.
On 6/11/15 2:30 PM, John Mazzitelli wrote:
FWIW: this is what the response would look like in my example if
a.war was undeployed:
{
"outcome" => "failed",
"result" => {
"step-1" => {
"outcome" => "failed",
"failure-description" => "JBAS014807: Management resource
'[(\"deployment\" => \"a.war\")]' not found",
"rolled-back" => true
},
"step-2" => {"outcome" => undefined}
},
"failure-description" => {"JBAS014653: Composite operation failed
and was rolled back. Steps that failed:" => {"Operation step-1" =>
"JBAS014807: Management resource '[(\"deployment\" =>
\"a.war\")]' not found"}},
"rolled-back" => true
}
----- Original Message -----
> Here's the use case: a monitoring app wants to monitor a WildFly instance -
> it will ask WildFly for the values of N attributes across M resources in one
> bulk composite request. This would avoid having to send one request for each
> individual attribute being collected (rather than one request for all of
> them at once).
>
> Is there a way I can configure a composite request such that WildFly will not
> abort the entire composite request if a single step to read an attribute
> fails?
>
> For example, suppose I send this - I'm basically asking Wildfly "tell me
the
> status of my two deployed applications a.war and b.war" :
>
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "read-attribute",
> "address" => [("deployment" =>
"a.war")],
> "include-runtime" => false,
> "name" => "status"
> },
> {
> "operation" => "read-attribute",
> "address" => [("deployment" =>
"b.war")],
> "include-runtime" => false,
> "name" => "status"
> }
> ]
> }
>
> Well, if someone undeployed a.war, that first step results in an error, but
> it also completely aborts the composite operation so I can't find the status
> of b.war either, unless a.war exists.
>
> I would like composites like this to tell me the status of every
> read-attribute - whether a failure or not. If not possible, I'm forced to
> split this up and make two individual requests for each attribute.
>
> Extrapolate that out - if I have N attributes I want to collect at the same
> time, I would be forced to make N individual requests rather than 1
> composite request just to avoid the case where if one of them failed, I
> would lose the data for all N.
> _______________________________________________
> 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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3:50 p.m.
/deployment=*:read-attribute(name=status,include-runtime=true)
Problem there is that would assume I am asking for the same attribute on the same type of
resource.
I'm monitoring pretty much everything (ok, not EVERYTHING), but the point is I might
be collecting one attribute for the transaction manager, one on a datasource, and one on a
deployment - different attributes across different types - but I'm collecting them all
at the same time. So I would like to do a bulk collection and just issue one request -
but it sounds like I need to split it up and shotgun N requests each asking for a singular
attribute value.
----- Original Message -----
> Try this:
>
/deployment=*:read-attribute(name=status,include-runtime=true)
>
> The composite op won't allow you to tell it ignore failures in reading
> the configuration model.
>
> On 6/11/15 2:30 PM, John Mazzitelli wrote:
> > FWIW: this is what the response would look like in my example if a.war was
> > undeployed:
> >
> > {
> > "outcome" => "failed",
> > "result" => {
> > "step-1" => {
> > "outcome" => "failed",
> > "failure-description" => "JBAS014807: Management
resource
> > '[(\"deployment\" => \"a.war\")]'
not found",
> > "rolled-back" => true
> > },
> > "step-2" => {"outcome" => undefined}
> > },
> > "failure-description" => {"JBAS014653: Composite
operation failed and
> > was rolled back. Steps that failed:" => {"Operation
step-1" =>
> > "JBAS014807: Management resource '[(\"deployment\" =>
\"a.war\")]'
> > not found"}},
> > "rolled-back" => true
> > }
> >
> > ----- Original Message -----
> >> Here's the use case: a monitoring app wants to monitor a WildFly
instance
> >> -
> >> it will ask WildFly for the values of N attributes across M resources in
> >> one
> >> bulk composite request. This would avoid having to send one request for
> >> each
> >> individual attribute being collected (rather than one request for all of
> >> them at once).
> >>
> >> Is there a way I can configure a composite request such that WildFly will
> >> not
> >> abort the entire composite request if a single step to read an attribute
> >> fails?
> >>
> >> For example, suppose I send this - I'm basically asking Wildfly
"tell me
> >> the
> >> status of my two deployed applications a.war and b.war" :
> >>
> >> {
> >> "operation" => "composite",
> >> "address" => [],
> >> "steps" => [
> >> {
> >> "operation" => "read-attribute",
> >> "address" => [("deployment" =>
"a.war")],
> >> "include-runtime" => false,
> >> "name" => "status"
> >> },
> >> {
> >> "operation" => "read-attribute",
> >> "address" => [("deployment" =>
"b.war")],
> >> "include-runtime" => false,
> >> "name" => "status"
> >> }
> >> ]
> >> }
> >>
> >> Well, if someone undeployed a.war, that first step results in an error,
> >> but
> >> it also completely aborts the composite operation so I can't find the
> >> status
> >> of b.war either, unless a.war exists.
> >>
> >> I would like composites like this to tell me the status of every
> >> read-attribute - whether a failure or not. If not possible, I'm forced
to
> >> split this up and make two individual requests for each attribute.
> >>
> >> Extrapolate that out - if I have N attributes I want to collect at the
> >> same
> >> time, I would be forced to make N individual requests rather than 1
> >> composite request just to avoid the case where if one of them failed, I
> >> would lose the data for all N.
> >> _______________________________________________
> >> 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
> >
>
>
> --
> 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
>
4:06 p.m.
You can include different wildcard reads as steps in a composite, if
that helps. The question is whether for each type of read, do you only
want specific resources (deployment=a.war,deployment=b.war), or do you
want all of that type?
Otherwise, yes, it would require a new feature to support ignoring
failures related to reading the configuration model.
Semi-OT: see https://issues.jboss.org/browse/WFCORE-287 for some new
querying functionality available in WF 10.
On 6/11/15 3:50 PM, John Mazzitelli wrote:
> /deployment=*:read-attribute(name=status,include-runtime=true)
Problem there is that would assume I am asking for the same attribute on the same type of
resource.
I'm monitoring pretty much everything (ok, not EVERYTHING), but the point is I might
be collecting one attribute for the transaction manager, one on a datasource, and one on a
deployment - different attributes across different types - but I'm collecting them all
at the same time. So I would like to do a bulk collection and just issue one request -
but it sounds like I need to split it up and shotgun N requests each asking for a singular
attribute value.
----- Original Message -----
> Try this:
>
> /deployment=*:read-attribute(name=status,include-runtime=true)
>
> The composite op won't allow you to tell it ignore failures in reading
> the configuration model.
>
> On 6/11/15 2:30 PM, John Mazzitelli wrote:
>> FWIW: this is what the response would look like in my example if a.war was
>> undeployed:
>>
>> {
>> "outcome" => "failed",
>> "result" => {
>> "step-1" => {
>> "outcome" => "failed",
>> "failure-description" => "JBAS014807: Management
resource
>> '[(\"deployment\" => \"a.war\")]'
not found",
>> "rolled-back" => true
>> },
>> "step-2" => {"outcome" => undefined}
>> },
>> "failure-description" => {"JBAS014653: Composite
operation failed and
>> was rolled back. Steps that failed:" => {"Operation
step-1" =>
>> "JBAS014807: Management resource '[(\"deployment\" =>
\"a.war\")]'
>> not found"}},
>> "rolled-back" => true
>> }
>>
>> ----- Original Message -----
>>> Here's the use case: a monitoring app wants to monitor a WildFly
instance
>>> -
>>> it will ask WildFly for the values of N attributes across M resources in
>>> one
>>> bulk composite request. This would avoid having to send one request for
>>> each
>>> individual attribute being collected (rather than one request for all of
>>> them at once).
>>>
>>> Is there a way I can configure a composite request such that WildFly will
>>> not
>>> abort the entire composite request if a single step to read an attribute
>>> fails?
>>>
>>> For example, suppose I send this - I'm basically asking Wildfly
"tell me
>>> the
>>> status of my two deployed applications a.war and b.war" :
>>>
>>> {
>>> "operation" => "composite",
>>> "address" => [],
>>> "steps" => [
>>> {
>>> "operation" => "read-attribute",
>>> "address" => [("deployment" =>
"a.war")],
>>> "include-runtime" => false,
>>> "name" => "status"
>>> },
>>> {
>>> "operation" => "read-attribute",
>>> "address" => [("deployment" =>
"b.war")],
>>> "include-runtime" => false,
>>> "name" => "status"
>>> }
>>> ]
>>> }
>>>
>>> Well, if someone undeployed a.war, that first step results in an error,
>>> but
>>> it also completely aborts the composite operation so I can't find the
>>> status
>>> of b.war either, unless a.war exists.
>>>
>>> I would like composites like this to tell me the status of every
>>> read-attribute - whether a failure or not. If not possible, I'm forced
to
>>> split this up and make two individual requests for each attribute.
>>>
>>> Extrapolate that out - if I have N attributes I want to collect at the
>>> same
>>> time, I would be forced to make N individual requests rather than 1
>>> composite request just to avoid the case where if one of them failed, I
>>> would lose the data for all N.
>>> _______________________________________________
>>> 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
>>
>
>
> --
> 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
5:35 a.m.
On 11 Jun 2015, at 23:06, Brian Stansberry wrote:
Semi-OT: see https://issues.jboss.org/browse/WFCORE-287 for some new
querying functionality available in WF 10.
This is awesome. Perhaps no exactly what is asked above, but I recall
talking about that years ago already.
I think the "ok to partially fail" flag for batches of read-* operations
may still be very helpful. If we talk to a DC and need data from
connected HCs (or even their managed servers), it is better to send
requests as batch instead of multiple single simple requests for
network latency reasons.
Heiko
3452
days inactive
3453
days old
5 comments
3 participants
participants (3)
-
Brian Stansberry -
Heiko W.Rupp -
John Mazzitelli