tag:blogger.com,1999:blog-7831813422886730737.post6298696618201871216..comments2023-10-08T10:44:28.524+03:00Comments on Event Processing Thinking: On Semantics and Race Conditions - introductionOpher Etzionhttp://www.blogger.com/profile/10791357917675270335noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-7831813422886730737.post-88123878022134939972008-10-02T13:09:00.000+03:002008-10-02T13:09:00.000+03:00An interesting design choice is to decide at what ...An interesting design choice is to decide at what time e4 is detected!<BR/><BR/>In this example it is detected a short while after e2. <BR/><BR/>Another option which we use in ruleCore is to consider e4 to be detected at the same time as e2. The motivation for this is that the first pattern consists of two events and when the second (e2) occurs, the pattern is considered to be detected at that exact time, and thus e4 will have that same timestamp.Mhttps://www.blogger.com/profile/15928652667178672308noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-84995752196186660122008-09-30T11:38:00.000+03:002008-09-30T11:38:00.000+03:00It all depends on semantics. If we take extremes: ...It all depends on semantics. If we take extremes:<BR/> - e4 may be an event related to an action that has started long before e1 and e2. For example, if I detect a wedding when all people come out of the chirch, the wedding has started some time ago. In this case e4 is completely out of order and related long in the past when it is generated.<BR/> - e4 may be a deduction for something that will happen and in this case e4 is well ordered compared to e1, e2 but still may be out of order compared to e3.<BR/><BR/>All this is linked to the difference between time of occuring (creation for a derived event), time of detection but also time of the happening of the thing the event is related to. It seems this is a 3 timestamps problem.<BR/><BR/>Fab.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-42843415490076441962008-09-30T09:16:00.000+03:002008-09-30T09:16:00.000+03:00Now this is an interesting situation ;)For ruleCor...Now this is an interesting situation ;)<BR/><BR/>For ruleCore this would trigger e5 every time - In the default configuration, flip a switch and you will never detect e5!<BR/><BR/>I suppose the main problem might be if the rightmost pattern detector sees e4 before seeing the next input which is e3. <BR/><BR/>We have a simple/primitive/efficient/naïve (pick one) solution/fix to this in ruleCore. Every event created by a pattern detector ('rule' in our world) is pushed out of the server and onto the input queue again. <BR/><BR/>So e4 will end up in the input queue as a newborn event e4', which has to created based on e4 and send back into the server again. So basically we create a new event, same content and same type, but with new id and time.<BR/><BR/>We have to do it this way to support multiple unsynchronized event sources where we need to keep every event in a sort buffer for a short while in order to resynchronize them. This allows us to receive events from slightly (the length of the temporal sort buffer) unsynchronized sources.<BR/><BR/>If we switch on internal event routing the semantics change to e5 never been detected. The e4 would be considered to be detected at the same timestamp as e2. As e3 occurs after e2 the this might be more correct as we would consider e4 to be before e3.<BR/><BR/>So this could be made to behave in two different ways depending on how the server is used. tricky indeed...Mhttps://www.blogger.com/profile/15928652667178672308noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-61130525307194373702008-09-29T23:47:00.000+03:002008-09-29T23:47:00.000+03:00As Paul implies, with the products that I have use...As Paul implies, with the products that I have used, there are several ways to code for this scenario and each will respond differently. <BR/><BR/>There is of course the issue of how the "time" of e4 is calculated. But even if we fix how this time is calculated, the answer will still depend on implementation.<BR/><BR/>A survey of techniques and resulting time semantics would probably be interesting, but I do know that most products at least will not give the non-deterministic answer here.Hanshttps://www.blogger.com/profile/03057096345613832279noreply@blogger.comtag:blogger.com,1999:blog-7831813422886730737.post-22024221199285357042008-09-29T19:56:00.000+03:002008-09-29T19:56:00.000+03:00Hi Opher - I guess it depends on what you mean by ...Hi Opher - I guess it depends on what you mean by a derived event having a "timestamp". And how you caclulate derived events' "occurred" or "detected" time. For which the answers are probably context-sensitive! <BR/>CheersAnonymousnoreply@blogger.com