[wildfly-dev] failures in composite operations

[Brian Stansberry]

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