flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-10267) [State] Fix arbitrary iterator access on RocksDBMapIterator
Date Tue, 11 Sep 2018 13:24:00 GMT

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

ASF GitHub Bot commented on FLINK-10267:

StefanRRichter commented on issue #6638: [FLINK-10267][State] Fix arbitrary iterator access
on RocksDBMapIterator
URL: https://github.com/apache/flink/pull/6638#issuecomment-420272898
   Thanks for the contribution! Looks good for me as well 👍 Merging.

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> [State] Fix arbitrary iterator access on RocksDBMapIterator
> -----------------------------------------------------------
>                 Key: FLINK-10267
>                 URL: https://issues.apache.org/jira/browse/FLINK-10267
>             Project: Flink
>          Issue Type: Bug
>          Components: State Backends, Checkpointing
>    Affects Versions: 1.5.3, 1.6.0
>            Reporter: Yun Tang
>            Assignee: Yun Tang
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.6.1, 1.5.4
> Currently, RocksDBMapIterator would load 128 entries into local cacheEntries every time
if needed. Both RocksDBMapIterator#next() and RocksDBMapIterator#hasNext() action might trigger
to load RocksDBEntry into cacheEntries.
> However, if the iterator's size larger than 128 and we continue to access the iterator
with following order: hasNext() -> next() -> hasNext() -> remove(), we would meet
weird exception when we try to remove the 128th element:
> {code:java}
> java.lang.IllegalStateException: The remove operation must be called after a valid next
> {code}
> Since we could not control user's access on iterator, we should fix this bug to avoid
unexpected exception.

This message was sent by Atlassian JIRA

View raw message