Hi Dawid, Thank you for the clarification. If possible can you please mention any example use case where we can know complexity of building nfa and why IGNORE action needs to be evaluated independently of TAKE action.
Thanks & Regards, Puneet Duggal On Mon, 1 Nov 2021 at 3:28 PM, Dawid Wysakowicz <dwysakow...@apache.org> wrote: > Hey Puneet, > > The reason for multiple calls to the condition is as mentioned before, > because once it is evaluated for the TAKE and the second time for the > IGNORE edge. The reason is that every edge is evaluated independently. > There is no joint context or caching of conditions. I agree from a > perspective of such a simple pattern it would make sense to evaluate it > just once for the TAKE. However, construction of the NFA is in general a > complicated (maybe even overcomplicated) process it becomes not that > obvious in more complex cases. > > Having said every edge is evaluated independently, we need to evaluate the > condition for the IGNORE edge, because we should IGNORE the element (or in > other words wait for a next element) only if we have not taken it. > Therefore the condition for the IGNORE edge is NOT(TAKE_CONDITION). > > Best, > > Dawid > On 29/10/2021 01:05, Puneet Duggal wrote: > > Hi Yun Gao, > > Thank you for the immediate response. You are correct that any state in > nfa will have 2 options.. either to TAKE(element) and undergo transition to > another state Or it can IGNORE and remain in its current state. But if a > state decides to ignore the element , then why will it evaluate itself with > the given element. What i mean is that regarding followedBy , only 2 > transitions are possible, TAKE and IGNORE. Why would pattern (state of NFA) > evaluate an element if it is undergoing IGNORE transition. Evaluation > should only happen for TAKE transition right? > > Thanks, > Puneet > > On Wed, Oct 27, 2021 at 7:26 PM Yun Gao <yungao...@aliyun.com> wrote: > >> Hi Puneet, >> >> Sorry I'm not be an expert for CEP, but the underlying implementation of >> the CEP should >> be based on the NFA, and from the API documentation, `followedBy` does >> not require the >> two patterns are adjacent (namely the give pattern also accepts ['a', >> 'c', 'b']. Thus when >> recieved 'a', I think the NFA might have two possible transitions, one is >> to accept 'b' >> and get a match, another one is to ignore 'b' and waiting for the >> following events, thus >> the condition might be eval for two times. >> >> Best, >> Yun >> >> >> ------------------Original Mail ------------------ >> *Sender:*Schwalbe Matthias <matthias.schwa...@viseca.ch> >> *Send Date:*Wed Oct 27 17:55:18 2021 >> *Recipients:*Puneet Duggal <puneetduggal1...@gmail.com>, user < >> user@flink.apache.org> >> *Subject:*RE: Duplicate Calls to Cep Filter >> >>> Hi Puneet, >>> >>> >>> >>> … not able to answer your question, but I would be curious to also >>> print out the value with your diagnostic message. >>> >>> … assuming we’ll see an ‘a’ and a ‘b’ for both filters resp. >>> >>> >>> >>> … simple explanation would be that the filters are applied to all input, >>> regardless of the pattern matching that follow the input filtering (just >>> guessing) >>> >>> >>> >>> Thias >>> >>> >>> >>> >>> >>> *From:* Puneet Duggal <puneetduggal1...@gmail.com> >>> *Sent:* Mittwoch, 27. Oktober 2021 11:12 >>> *To:* user <user@flink.apache.org> >>> *Subject:* Duplicate Calls to Cep Filter >>> >>> >>> >>> Hi, >>> >>> >>> >>> I am facing an issue where a single event is causing execution of a >>> cep filter multiple times. I went through this video >>> <https://www.youtube.com/watch?v=XRyl0RGWs1M> explaining automata >>> formation from pattern sequence but it still does not explain the behaviour >>> that I am facing. Following is the sample pattern for whichI am testing >>> this behaviour. >>> >>> Pattern<String, ?> innerPattern = >>> >>> Pattern >>> >>> .<String>begin("start") >>> >>> .where(new SimpleCondition<String>() { >>> >>> @Override >>> >>> public boolean filter(String value) throws >>> Exception { >>> >>> System.out.println("In the beginning"); >>> >>> return value.equals("a"); >>> >>> } >>> >>> }) >>> >>> .followedBy("middle") >>> >>> .where(new SimpleCondition<String>() { >>> >>> @Override >>> >>> public boolean filter(String value) throws >>> Exception { >>> >>> System.out.println("In the middle"); >>> >>> return value.equals("b"); >>> >>> } >>> >>> }); >>> >>> On passing events *a* and *b* to this pattern.. result is >>> >>> 1> a >>> >>> In the beginning >>> >>> 1> b >>> >>> In the middle >>> >>> In the middle >>> >>> In the beginning >>> >>> Matched >>> >>> 3> {start=[a], middle=[b]} >>> >>> As you can see ... on ingestion of *b* middle pattern is getting called >>> twice. Any ideas of this behaviour. >>> >>> >>> >>> Thanks and regards, >>> >>> Puneet Duggal >>> Diese Nachricht ist ausschliesslich für den Adressaten bestimmt und >>> beinhaltet unter Umständen vertrauliche Mitteilungen. Da die >>> Vertraulichkeit von e-Mail-Nachrichten nicht gewährleistet werden kann, >>> übernehmen wir keine Haftung für die Gewährung der Vertraulichkeit und >>> Unversehrtheit dieser Mitteilung. Bei irrtümlicher Zustellung bitten wir >>> Sie um Benachrichtigung per e-Mail und um Löschung dieser Nachricht sowie >>> eventueller Anhänge. Jegliche unberechtigte Verwendung oder Verbreitung >>> dieser Informationen ist streng verboten. >>> >>> This message is intended only for the named recipient and may contain >>> confidential or privileged information. As the confidentiality of email >>> communication cannot be guaranteed, we do not accept any responsibility for >>> the confidentiality and the intactness of this message. If you have >>> received it in error, please advise the sender by return e-mail and delete >>> this message and any attachments. Any unauthorised use or dissemination of >>> this information is strictly prohibited. >> >>
