XTemp-wd-rev087

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

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?
  

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

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

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

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

• 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).

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

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

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

Regards,
Marius Plavan