[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tamie-comment] XTemp-wd-rev087
Hi Marius: Thanks – great comments - my answers inline (JD). -jacques From: Marius Plavan [mailto:marius.edtf@gmail.com] Hi all,
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 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).
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.
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.
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 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.
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.
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.
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…
JD: Absolutely. This why we do not want to distinguish “simulated” and “real” concurrency other than by implementation aspects or timing during execution.
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]