[wildfly-dev] failures in composite operations

[Brian Stansberry]

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 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
>>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat