-
Notifications
You must be signed in to change notification settings - Fork 30
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
Labels
Comments
Currently this is the way to detect if a rule is a timedRule (in perseo-fe and perseo-core): Lines 84 to 93 in 4940ba7
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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):
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))]
The text was updated successfully, but these errors were encountered: