tamie-comment message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: XTemp-wd-rev087
- From: Marius Plavan <marius.edtf@gmail.com>
- To: tamie-comment@lists.oasis-open.org
- Date: Sun, 23 Jan 2011 11:49:52 +0100
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]