In my previous mail: total time spent should have been = T0 + T1 + P3DT12H.
<JD> see my comments to your previous mail, below: the @tryfor starts “counting” as soon as the <catch> starts executing (VP-time at the moment).
After putting more time on this, the catch/@tryfor description adheres to what one would expect (so my previous uncertainty about Step 2 and @tryfor is no longer there if one reads the below):
---Section 4.7.3
catch/@tryfor: a duration that indicates how long the catch operation may "try" to select an event
(or a combination of) that satisfies the defined pattern
---
So basically, in "deferred mode" and "live mode", the important thing is that the user specified @tryfor value is part of the "compound condition" (i.e. the XPath query which will be executed on all the events from the Event Board).
<JD> yes I think. See however the twist when <catch> is catching past events as well (even in live mode, see Ex 2 in 4.7.4). The timeout @tryfor is meaningless for these.
In "live mode", the "compound condition" stays the same, but additionally I need another (internal XSLT) variable (let's call it timeSpentWithCatching) to keep count on the overall time spent inside <catch>.
When timeSpentWithCatching > @tryfor, than the "event manager" running in the extension function will stop querying for events.
<JD> that sounds right. In live mode, the execution of the <catch> should never last more than @tryfor. If by then no event pattern was found , then the new VP-time is incremented to the end of the @tryfor (i.e. VP-time at <catch> start + @tryfor)
Merry Christmas,
Marius Plavan
On Wed, Dec 21, 2011 at 8:51 PM, Marius Plavan <marius.edtf@gmail.com> wrote:
Hi all,
Regarding the catch/@tryfor attribute, I would like to raise a few questions.
The "catch timeout" handling for XTemp / "Live mode" is about to be implemented in edtf, so I would like to clarify some uncertainties that I have.
Let's take a simple example:
---
<catch eb="POs" tryfor="P3DT12H" >
<match event="PO"<condition>...</condition></match>
</catch>
---
In the above case, this means that <catch> will block for the specified duration. Crystal clear.
<JD> It will not block for the entire P3DT12H duration, in case an event matching the condition occurs before that, though.
Now we take a more complex example (although the below is not currently supported by edtf), which contains more <match> elements:
---
<catch eb="POs" tryfor="P3DT12H" >
<match event="PO"<condition>...</condition></match>
<match event="POresponse" after="PO"<condition>...</condition></match>
<match event="POreceipt" after="POresponse"<condition>...</condition></match>
</catch>
---
For the above <catch>, lets assume "PO" is catched at T0, Does this imply that POresponse should be catched in P3DT12H or (P3DT12H - T0) ?
<JD> Yes: @tryfor defines a timeout for the entire event pattern: “…how long the catch operation may "try" to select an event (or a combination of) that satisfies the defined pattern…”. Please note however that the ordering of <match> statements does not necessarily match the time order (see Example #2 in 4.7.4): You could start with <match event="POresponse" > catching a response at time T0, then the second match would be <match event="PO">, finding the past PO event corresponding to this response (this would be a good way to proceed if you are only interested in Pos that have a response, so you don’t catch useless POs):
<catch eb="POs" tryfor="P3DT12H" >
<match event="POresponse><condition>...</condition></match>
<match event="PO" before="POresponse > <condition>...</condition></match>
<match event="POreceipt" after="POresponse"<condition>...</condition></match>
</catch>
Then the <<match event="POresponse" > would have to be caught within (P3DT12H - T0) for the catch to succeed, so the entire event pattern could actually last more than P3DT12H: this duration is more like a maximum time limit that the <catch> to *execute*.
In XTemp spec, section 4.7.3, Step 2, the answer seems to be pretty clear: "the event occurs before the catch timeout (@tryfor)" (i.e. in the 2nd example, POresponse should be catched in P3DT12H).
This means that if POresponse will be catched at T1 and POreceipt will not be catched, the event pattern was not found (total time spent = P3DT12H + T1 + P3DT12H) and a new event pattern will be initiated with "PO".
<JD> In example #2 (4.7.4), POresponse should be caught within P3DT12H from the VP-time (called here Vptime0) at which the <catch> starts executing. Say it is caught at T1, Then there is only P3DT12H – duration(T1 – Vptime0) left for the POreceipt to be caught. In other words, when the <catch> executes in example #2, both POresponse and related POreceipt must be caught within P3DT12H. Note: if the PO event was not found among past events, the <catch> fails.
But long time ago when I first saw a <catch> with @tryfor, it was in an XTemp script.
Only by looking at the <catch> (and without reading the spec), I had a (high) expectation that @tryfor applies for the entire <catch> (i.e. in the 2nd example, POresponse should be catched in P3DT12H - T0).
This expectation came from the fact that @tryfor was a <catch> attribute, not a <match> attribute.
So, if this feeling is shared by more of us, I would kindly ask if either one of the below can be an option for the future..
- make @tryfor available only as part of the <match>, which would give the user extra flexibility in specifying timeouts inside a catch or
- leave @tryfor where it is now and make it also available for <match>, which would make things backward compatible at a syntactic level but not on a semantic one (as catch/@tryfor timeout will apply to all <match> statements cumulatively) or
- change @tryfor name to better reflect the fact that the timeout applies for each <match>
<JD> Allowing @tryfor on both <catch> and <match> might be confusing… It is indeed designed as an execution timeout for the entire <catch>, not so much for each match inside. But if you want a <match> to be restricted in time , you could still express a time condition inside this match, e.g. say, match #2 should not happen later than time(match #1) + some duration). Every event already caught in a pattern can be used in a condition using its symbolic name as variable, e.g. $E2//@timestamp. Can you provide us with a concrete use case where @tryfor would be desired on <match>?
Thank you in advance for your answers.
Best regards,
Marius Plavan