[
https://issues.apache.org/jira/browse/FLINK-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058947#comment-16058947
]
Dawid Wysakowicz edited comment on FLINK-6983 at 6/22/17 8:15 AM:
------------------------------------------------------------------
Just a copy of the start of the discussion from a PR:
dianfu:
{quote}
Just one comment: the states in NFA is metadata, maybe we should get rid of
serializing them at all?
{quote}
dawidwys:
{quote}
I agree that we should consider removing states from serialization, but I have
some concerns about it:
1. States are part of ComputationStates which describe partial matches, which
means they are definitely not metadata. If we do not want to store States, I
think we will be forced to either drop checkpointing of partial matches or
implement logic of translating them to newly constructed graph of states, which
I think would be hard if possible at all.
2. One feature I would like to see in FlinkCEP library is dynamically providing
new Patterns(e.g. through Side Inputs), I think in this case States serializing
will be crucial.
{quote}
dianfu:
{quote}
In my mind, to achieve translating them to newly constructed graph of states,
we only need to get the state from the NFA by the state name stored in
ComputationState. Not sure if my understanding is correct?
For dynamically providing new Patterns, do you mean dynamically changing the
NFA? Another approach coming into my mind is that we can store the states in
another ValueState(compared with the partially matched events and
ComputationStates stored) and only update it if the NFA changes. What's your
thought?
{quote}
was (Author: dawidwys):
Just a copy of the start of the discussion from a PR:
dawidwys:
{quote}
I agree that we should consider removing states from serialization, but I have
some concerns about it:
1. States are part of ComputationStates which describe partial matches, which
means they are definitely not metadata. If we do not want to store States, I
think we will be forced to either drop checkpointing of partial matches or
implement logic of translating them to newly constructed graph of states, which
I think would be hard if possible at all.
2. One feature I would like to see in FlinkCEP library is dynamically providing
new Patterns(e.g. through Side Inputs), I think in this case States serializing
will be crucial.
{quote}
dianfu:
{quote}
In my mind, to achieve translating them to newly constructed graph of states,
we only need to get the state from the NFA by the state name stored in
ComputationState. Not sure if my understanding is correct?
For dynamically providing new Patterns, do you mean dynamically changing the
NFA? Another approach coming into my mind is that we can store the states in
another ValueState(compared with the partially matched events and
ComputationStates stored) and only update it if the NFA changes. What's your
thought?
{quote}
> Do not serialize States with NFA
> --------------------------------
>
> Key: FLINK-6983
> URL: https://issues.apache.org/jira/browse/FLINK-6983
> Project: Flink
> Issue Type: Improvement
> Components: CEP
> Reporter: Dawid Wysakowicz
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
