[ 
https://issues.apache.org/jira/browse/FLINK-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477556#comment-16477556
 ] 

ASF GitHub Bot commented on FLINK-9373:
---------------------------------------

Github user StefanRRichter commented on the issue:

    https://github.com/apache/flink/pull/6020
  
    It depends, maybe this is already covered currently because we might always 
do an iteration attempt that checks right after the seek. But in general, this 
is not very nice and fragile if true.


> 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)

Reply via email to