[
https://issues.apache.org/jira/browse/FLINK-9642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540114#comment-16540114
]
ASF GitHub Bot commented on FLINK-9642:
---------------------------------------
Github user dawidwys commented on the issue:
https://github.com/apache/flink/pull/6205
Hi @Aitozi ,
Thanks for the work here. I think we could improve a bit separation of
concerns in the SharedBuffer. I am a bit afraid this class will become too
complex once again. How about we split the SharedBuffer into two layers:
caching one(SharedBuffer) and accessing buffer e.g. `SharedBufferAccessor`. We
could make the accessor `AutoCloseable`. I think it would give more explicit
information about the necessity to flush the buffer.
We could move to `SharedBufferAccessor` methods like:
- registerEvent
- put
- extractPatterns
- materializeMatch
- materializeMatch
- lockNode
- releaseNode
- removeNode
- lockEvent
- releaseEvent
In the `SharedBuffer` we would leave only the caching package-protected
methods. We would also add a method there to get the `SharedBufferAccessor`
that would `flush` the changes on `close`. This way we would have a cleaner
separation, plus we would make the flushing more intuitive.
What do you think?
> Reduce the count to deal with state during a CEP process
> ---------------------------------------------------------
>
> Key: FLINK-9642
> URL: https://issues.apache.org/jira/browse/FLINK-9642
> Project: Flink
> Issue Type: Improvement
> Components: CEP
> Affects Versions: 1.6.0
> Reporter: aitozi
> Assignee: aitozi
> Priority: Major
> Labels: pull-request-available
>
> With the rework of sharedBuffer Flink-9418, the lock & release operation is
> deal with rocksdb state which is different from the previous version which
> will read the state of sharedBuffer all to memory, i think we can add a cache
> or variable in sharedbuffer to cache the LockAble Object to mark the ref
> change in once process in NFA, this will reduce the count when the events
> point to the same NodeId.. And flush the result to MapState at the end of
> process.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
