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 > <mailto: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 > <mailto:matthias.schwa...@viseca.ch>> > *Send Date:*Wed Oct 27 17:55:18 2021 > *Recipients:*Puneet Duggal <puneetduggal1...@gmail.com > <mailto:puneetduggal1...@gmail.com>>, user > <user@flink.apache.org <mailto: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 > <mailto:puneetduggal1...@gmail.com>> > *Sent:* Mittwoch, 27. Oktober 2021 11:12 > *To:* user <user@flink.apache.org > <mailto: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 amtesting 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. >
OpenPGP_signature
Description: OpenPGP digital signature
