[wildfly-dev] failures in composite operations

[John Mazzitelli]

> /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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> > _______________________________________________
> > 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
>