Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FROM PATTERN "Mixed" TimeRules and EventRules are not working properly (wrong context) #501

Open
mrutid opened this issue Mar 5, 2021 · 1 comment
Assignees
Labels

Comments

@mrutid
Copy link
Member

mrutid commented Mar 5, 2021

Time Rules are created in a CONTEXT like:

create context TIMER$SERVICE$SSERVICE start @now

Which is necessary in order to activate it immediately, avoiding the need to wait for an initial event to do it. In this way Time Rules will be active after a CEP restart or at subservices without events.

Take into account that all events from all services are reaching this context. It's weird but it's not a big problem since we don't use events in basic Time Rules.

In "no time rule", lets call it Event Rule, context has the form:

create context CTX$SERVICE$SSERVICE partition by service from iotEvent(service="SERVICE" and subservice="SSERVICE")

This context just receives events from a given services and subservice but it doesn't activate until the first event reach it (so Timer Rules won't trigger if there is no initial event).

BUT what happened when we have a mixed rule which is a Time Rule and an Event Rule?
SELECT * FROM PATTERN [ EVERY a=iotEvent -> (timer:interval(10 sec) AND NOT b=iotEvent (a.id is b.id))]

The above is considered a Time Rule by the CEP (since it has the "timer:" substring) who add it to the corresponding TIMER$SERVICE$SSERVICE context but... since there is no filtering or partition the rule is processing every single event from every service and subservice (and getting triggered by all of them).

Since this concrete rule will need an iotEvent to work properly it will fit much better in the event rule context CTX$SERVICE$SSERVICE, but since being a Time rule has more implications that just the context maybe it won't work, maybe we still need to use the TImeRuleStore or so (since it is not fired directly by an event and maybe some information could be missing like in Time Rules)...

So it could be (and need to be tested):

  • a TimerRule which needs the Event Rule context
  • an propper EventRule

The way to discriminate could be just look for the substring "iotEvent", but probably it wont work think of rules that start with a timer like:
SELECT * FROM PATTERN [ EVERY (timer:interval(10 sec) -> a=iotEvent ]

They still needing an "start @now" context, but just the S/SS Events. This rules are right now not being used in any use case.

PERSEO_CORE NOTICE: Time Rules has also a special treatment at Perseo Core some changes may apply also.

WORKAROUND

In the meantime it is necessary to make the filtering in the rule itself just by adding:
SELECT * FROM PATTERN [ EVERY a=iotEvent(a.service="SERVICE" and a.subservice="SUBSERVICE") -> (timer:interval(10 sec) AND NOT b=iotEvent((b.service="SERVICE" and b.subservice="SUBSERVICE") and a.id is b.id))]

@AlvaroVega
Copy link
Member

AlvaroVega commented Jul 7, 2023

Currently this is the way to detect if a rule is a timedRule (in perseo-fe and perseo-core):

function isTimedRule(rule) {
// Detect timed rules, taken from perseo-core
// https://github.com/telefonicaid/perseo-core/blob/master/perseo-main/src/main/java/com/telefonica/iot/perseo/TimeRulesStore.java#L110
return (
(rule.text && rule.text.includes('timer:')) ||
(rule.text &&
rule.text.toLowerCase().includes('match_recognize') &&
rule.text.toLowerCase().includes('interval'))
);
}

https://github.com/telefonicaid/perseo-core/blob/9612ab05f5d706930679aa35980c597f9922b288/perseo-main/src/main/java/com/telefonica/iot/perseo/TimeRulesStore.java#L110-L118

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants