Re: [tamie-comment] XTemp-wd-rev087

[Marius Plavan <marius.edtf@gmail.com>]

Hi Jacques,

Thank you also for your answers. They clarified my open points.
I also think that by providing choice through the configurable time-stamp is a better approach.

For my project, I'm now about to start thinking about the <catch> design & implementation (using an extension function), so that it can accommodate with the exiting XTemp draft requirements.

In this moment, I'm not really convinced how much of the <catch> implementation should stay in the translator and how much should be coded in Java inside the extension function.
On one side I like keeping it as much as possible inside the translator because it can be easier to modify by someone else, if needed.
On the other side, keeping the entire catch implementation inside the extension function might allow for a few optimization tricks.
And if I land somewhere in the middle, would mean to implement only the <match> as an extension function, which would made the extension function implementation quite straight forward.
Anyway, I have to read and evaluate the spec again to make sure I did not missed anything important about it.

Going back to the <catch>, in the latest XTemp draft v0.93:

• page 34: Step 2:  the next "match" statement (next "match" sibling) of the catch is executed. The event search for this event is no longer conditioned by the VP-time, i.e. could search for events before the lead event (past events) or "wait" (really or virtually) for some event after the lead event, depending on ordering constraints stated in the match  e.g.  as specified by the attribute match/@after. For this "match", the eligibility conditions are:
  

     - the event is not previously masked by any scriplet instance of the same package execution instance.
     - the event occurs before the catch timeout (@tryfor)
     - the event satisfies the selection condition for this match, which generally correlates with previously selected events.  (e.g. via variables defined in preceding "match" siblings).
If there is failure to match an event for this filter - e.g. a POresponse event did not occur before the catch timeout  - then the pattern detection resumes to Step 1, for catching the next "lead" event after the timestamp  of the previous lead event attempt.

• Related to the last phrase:

If there is failure to match an event for this filter - e.g. a POresponse event did not occur before the catch timeout  - then the pattern detection resumes to Step 1

As I read it, it is assumed in that phrase that there is no @tryfor value present. Because if it was, how can we determine if there was a failure in Step 2 so that we can resume to Step 1? A @tryfor would mean to try until the timeout expires, so in that case no resume is possible. Am I missing something?

• page 35: element xtemp:match {  match_body }
  

match_body =
        attribute event {xsd:normalizedString} ? ,
        attribute view {xsd:normalizedString} ? ,
        attribute before {NCName} ? ,
        attribute after {NCName} ? ,
        attribute min {xsd:integer} ? ,
       
        element  xtemp:condition { condition_body } *

condition_body =
    attribute key {xsd:normalizedString} ? ,
    xsd:normalizedString

• Regarding the match/@event: shouldn't this attribute be mandatory? It is the only way through which we can later reference an event which matched (or not). Or is there another semantic for not being mandatory?
• On the same line, I assume that also when <catch> fails, all the match/@event will leave behind an empty variable.
  

That would be all for today. Have a nice week-end!

Regards,
Marius Plavan

On Mon, Jan 24, 2011 at 9:23 PM, Jacques Durand <JDurand@us.fujitsu.com> wrote:

Hi Marius:

 

Thanks – great comments - my answers inline (JD).

 

-jacques

 

From: Marius Plavan [mailto:marius.edtf@gmail.com]
Sent: Sunday, January 23, 2011 2:50 AM
To: tamie-comment@lists.oasis-open.org
Subject: [tamie-comment] XTemp-wd-rev087

 

Hi all,

I took some time last week-end to address some open questions that I have and which are related to the most recent XTemp spec.
A couple of questions based on XTemp-wd-rev087 can be found below.

• page 8: Events: these are Xtemp -formatted XML events posted to an Event Board. A log of such events may be the preferred format for results of monitoring or testing. Outputs in form of events also allow for dynamic coordination between concurrent  scripts, as well as pipe-line processing of test material.

• "concurrent scripts" in this context are referring to <script-package>'s or <scriplet>'s?

JD: scriplets inside the same package, can execute “concurrently”.  Incidentally, nothing prevents two “packages” to execute concurrently on the same event Board, but that is out of scope of the specification. We’ll make that clearer.

 

• page 10: S1 then wants to correlate the POI event with its related PO event, which occurred some time before. But since it is only interested in timely PO error reports, it will search for PO events that are 2 days or less prior to their POI notice. S1 can then start another scriplet S2 to catch the related PO  and set the VP-time of S2 to a date minus two days from its own VP-time.  In this case, the event search will be efficient because limited to a small subset of the event board.

page 41: timePost:  a date/time value representing the event posting time (different from the event creation or origination time as set by the  event originator). This value is automatically assigned by the event manager. It defines a partial order over the events of an event board, because two events could have the same timePost value. However, the timePost ordering is consistent with the ID ordering: for any two events E1 and E2, timePost(E1) < timePost(E2) => ID(E1) < ID(E2).

• Perhaps I am wrong here (again), but as I read it, the VP time "can be same as or different from the actual execution time". This is OK as long as event/@post-time is not in the picture.

• So, the post-time is the time the event was posted on the event board (in live or deferred mode), which means that, in this scenario, S2 above can indeed catch events (using a VP Time of "minus two days" from VP Time of S1) only when the events are inserted in the event board in "Live mode", because only then the post-time of the events is matching the business time, so VP Time = Event Business Time.

 

JD: Right, I think the notion of posting time is misleading and too restrictive. Instead, we may use a more abstract notion of timestamp, which could be a business time OR the posting time, depending on EB configuration. How about:

R2: Each event has a “timestamp” - a date/time attribute that represents the occurrence time of the event . This attribute must be identified and accessed in the same way for all events of a same type in the same event-board. The timestamp is considered as the time at which the event occurred from an XTemp processing viewpoint and is the only date/time that is taken into account by the XTemp engine, when catching events occurring after a given VP-time. The timestamp may be different from the event creation time or “business time” as set by the event originator – e.g. the business time is a purchase order creation time, while the timestamp may be the time at which the PO message was actually captured and posted to the event board by the monitoring system. Which one of the possibly multiple date/time items associated with an event should be used as timestamp is a configuration choice. In case the business time is not used as timestamp, it is still accessible to scriplets as any other event data item and may be used in event selection expressions – it is simply not the date/time the XTemp engine will refer to when comparing the event time to VP-time or when setting the next VP-time value.

 

• If we are in deferred mode (so events were recorded and now they are re-inserted in the Event Board through the Event Adapter -- so we do not make any assumptions about an implicit order between events that are sent to the event adapter -- for example, when using several event adapters for feeding the same event board), then the VP Time will be different than the "event business time", so subtracting 2 days in this case will not be what we would expect.

• I think the only way this would work as intended is when the "event business time" is always present in the <event>, and the VP time is making use of that time to catch events. This "event business time" I see it as a "one time only" time stamp applied on the <event> when the system under test / monitoring is sending a message to the Event Adapter. Given that now we have the actual business time in the <event>, catching is more accurate if it's based on this time.

 

JD: The posting time would indeed be meaningless if an event adapter is posting bundles of events at arbitrary times for convenience. In fact, the most recent specification upgrade (with <eventbind> element) allows for configuring in an event board which data field in its events should be used as “posting time” (or rather, as significant timestamp) : eventbind/@post defines an XPath that leads to the date/time of interest to be used as timestamp in the event. I will propose to remove any “posting” semantics, e.g. rename eventbind/@post and event/@post-time into respectively: eventbind/@timestampexpr and event/@timestamp.

 

• Another dangerous semantic misinterpretation that I am getting into is when one does a <post> and then the event/@post-time is used (by another scriplet which catches that event) with the semantic of the "business time"..

• So if the concepts are separated, then things might be easier to grasp:

• the "event business time" is the time when the event happened in reality. VP-time can safely use the business time (in both live and differed mode) as an accurate time of when that event occurred.

• this then transfers the VP-time related requirements to the Event Adapter, which is responsible for properly assigning or ignoring the event business time (depending on whether we run in live or deferred mode).

• the "event post time" (i.e. event/@post-time) is the time when the event was recorded on the event board (which can be close or far from the business time). It can be used for synchronization between scriplets or something else..

• What do you think? Did I missed something in the judgment above?

 

JD: You are right that the emphasis on “posting time” is not good. The actual posting time should not be considered meaningful, except when there is no other notion of “business time” of interest in the event. In such a case the event board will  by default assign a timestamp, e.g. by using the current VP-time for this (that can be the case for scriplet-generated events used for synchronization). So the central notion should be a more abstract notion of “timestamp” which is to be considered for event ordering and VP-time semantics. The event board configuration is where to specify how to find in the event this timestamp: may be the business time of the event, or might be the “monitoring” time, or yet the time the event is posted to the EB, in case this time is considered meaningful enough for VP-time semantics (e.g. if this posting time is not too “delayed” or too far from business time, or if there is no business time field).

 

• page 9: A scriplet defines a flow (or thread) of execution for a sequence of atomic operations.

page 11: The real meaning of concurrency is how the VP-time of the invoking scriplet (S1) is managed.

page 12: (c) thread semantics: a scriplet executes its operations in one thread. However, a scriplet can invoke another scriplet "concurrently", meaning that both scriplets execute concurrently afterward. In such cases there is an implicit "joining" of all scriplets started from a (parent) scriplet: the parent only completes its execution after all children scriplets - either serial or concurrent - terminate.

page 13: when concurrent="true", the started scriplet is invoked concurrently. This means that the next statement in the invoking scriplet, will execute at a VP-time that is same as the VP-time value just before executing the <start> statement.

• To me at least, it is not crystal clear whether XTemp is promoting a "simulated concurrency" (VP Time being the only thing which is managed differently in case of a concurrent scriplet; as in page 11) or a "real concurrency" (the scriplet being always executed in another OS thread and the VP Time being handled as explained in page 11).. or both.

JD: Both. But “Simulated concurrency” is definitely an important goal as it is sufficient for all deferred executions, and also in many live execution cases where real-time response may not be so critical. XTemp could of course be executed using a “real” multi-threaded language as underlying implementation, but that is not a necessity – just an implementation choice. Bottom-line is we want all XTemp script packages (concurrent or not) to be executable on single-threaded systems, knowing very well that if timely alarm generation is critical then you better use a multi-threaded system. A practical goal is to be able to use our (single-threaded) XSLT prototype, to help develop and debug a script package.

• If we are dealing with a "simulated concurrency":

• Now thinking about cases when one wants to perform a "deferred event analysis / monitoring" using XTemp, the design I think is fine enough.

• Of course, such a simulated concurrency design can be easily used without an XTemp engine, which is a key advantage.

• But when thinking about "live analysis / monitoring / testing / simulation", I perceive the limitation (of not having the <scriplet> as a real OS thread) as a major one. When running live, you would expect that the framework is able to respond as quickly as possible to given events (also adhering to some custom SLAs).

 

JD: Good point. When events have to be “quickly” responded to (meaning by posting a new event), you want the “responding” thread to not be delayed too much. But even with a single-threaded implementation you could still decide to serialize concurrent scriplets in a smart way – a smart analysis of the scriplet package by the engine will allow to execute the most “urgent” scriplet first. Now of course, two concurrent scriplets could equally be “urgent”, both sending alarms. So here yes you may want to defer to a real multi-threaded system, as a coarse-grained sharing of engine time will not do. But I see this as an implementation issue – not an Xtemp limitation.

• So for the above reasons, I think that the concurrent scriplet needs to be an OS thread when using an XTemp engine.

• This of course complicates a little bit the design on one side, but on the other side it delivers the real concurrency that I believe is critical for the end-user.
• There might also be some compatibility challenges between the "simulated concurrency" and "real concurrency" (like passing context to the concurrently scriplet, like parameters, etc), which needs to be addressed in the design..

JD: Normally the design should not have to be different in both cases – just quantitative execution factors like timeliness of responses may be. SO if you see a fundamental incompatibility in supporting both “simulated” and “real” concurrency, we need to hear about it…

• Ideally, running the same XTemp script using both simulated and real concurrency implementations should have the same result (at least when not looking for specific SLAs), which is something that XTemp engine implementation should take care.

JD: Absolutely. This why we do not want to distinguish “simulated” and “real” concurrency other than by implementation aspects or timing during execution.

• page 29: catch/match/@min: determines the minimum number of matching events to select, in order to consider the match as successful. (default = 1) catch/match/@max: determines the maximum number of matching events to select (default = 1)

• As far as I understand, the @min = 1 tell us to return from the catch after one pair of events (that are matching all the filters in this <catch>) are gathered, right?

JD: if you want to select one pair of events, then you need @min = 2. As soon as two events match the condition, the <catch> terminates and returns these two events in the variable definition in which the catch is embedded.

o    If so, what happens when @min and @max are 2? How do we name the variables which will hold the events for the 2nd pair of matched events?

JD: The semantics of @max has always been a bit ambiguous. I now think that @max is not very useful (its role was more like deciding that if too many events match the condition within the catching window, then the catch fails – but this can be tested easily in other and more flexible ways).  So I’d propose we remove this attribute.

 

Regards,
Marius Plavan