flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From yestinchen <...@git.apache.org>
Subject [GitHub] flink issue #4331: [FLINK-7169][CEP] Support AFTER MATCH SKIP function in CE...
Date Fri, 28 Jul 2017 01:56:22 GMT
Github user yestinchen commented on the issue:

    @dawidwys Thanks for the reviewing. 
    Problem 1 is easy to fix, we can just start a new match process if the only left computation
state reaches stopState.
    Problem 2 can not be avoided with current approach.  It's impossible to know whether there
are potential matches. 
    I think the best wary to implement this correctly is try to start a new match process
after processing each event, and discard unfinished match process after a successful match
according to the skip strategy. In order to do that, we need to keep the logical order of
the events, which is the original idea I proposed. 
    As for your general notes, I have some ideas:
    1. I agree that the Oracle's specification is designed for bounded data. But match recoginize
in unbounded data is very similar to bounded data, since all data are being processed one
by one, and there's no need for bound information. As for **_empty match_** , I think we can
just use Oracle's definition.
    > Some patterns permit empty matches. For example:
    PATTERN (A*)
    can be matched by zero or more rows that are mapped to A.
    An empty match does not map any rows to primary row pattern variables; nevertheless, an
empty match has a starting row. For example, there can be an empty match at the first row
of a row pattern partition, an empty match at the second row of a row pattern partition, etc.
An empty match is assigned a sequential match number, based on the ordinal position of its
starting row, the same as any other match.
    2. I feel uncomfortable with the RuntimeExceptions too. But these exceptions are very
important to keep the skip semantics right. I understand your main concern is that Exceptions
will stop the matching process, which is unacceptable to online streaming service. To address
this, I think we can introduce a default strategy(SKIP_TO_NEXT_EVENT, for example). If these
exceptions happens, we can use default strategy to continue the match process, and change
the strategy back after a successful match. We can also add a switch to let user decide whether
to enable this feature.
    3. I still think it's useful to support these skip strategies. Don't know why Esper does
not support them.
    4. Thanks for the related information. I took a brief look at the PR, which is very similar
to this PR. I  wonder why it is closed without merging into the master code?
    Looking forward to your feedbacks. Thanks.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.

View raw message