[
https://issues.apache.org/jira/browse/FLINK-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477438#comment-16477438
]
ASF GitHub Bot commented on FLINK-9373:
---------------------------------------
Github user sihuazhou commented on the issue:
https://github.com/apache/flink/pull/6020
@StefanRRichter I had a look at the implementation of the iterators in
RocksDB, I found status just return the flag first `_status` as the result
without any complex computation, But for some `composite Iterator` like the
`MergeIteraor` and `TwoLevelIterator` it need to check all the
`InternalIterator` they hold to decide the final status, and I also found the
iterator could be reset to `OK` in some cases...Hmm...do you think this is
super cheap or not?
> Fix potential data losing for RocksDBBackend
> --------------------------------------------
>
> Key: FLINK-9373
> URL: https://issues.apache.org/jira/browse/FLINK-9373
> Project: Flink
> Issue Type: Bug
> Components: State Backends, Checkpointing
> Affects Versions: 1.5.0
> Reporter: Sihua Zhou
> Assignee: Sihua Zhou
> Priority: Blocker
> Fix For: 1.5.0
>
>
> Currently, when using RocksIterator we only use the _iterator.isValid()_ to
> check whether we have reached the end of the iterator. But that is not
> enough, if we refer to RocksDB's wiki
> https://github.com/facebook/rocksdb/wiki/Iterator#error-handling we should
> find that even if _iterator.isValid()=true_, there may also exist some
> internal error. A safer way to use the _RocksIterator_ is to always call the
> _iterator.status()_ to check the internal error of _RocksDB_. There is a case
> from user email seems to lost data because of this
> http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/Missing-MapState-when-Timer-fires-after-restored-state-td20134.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)