[
https://issues.apache.org/jira/browse/HBASE-14549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14951645#comment-14951645
]
Lars Hofhansl commented on HBASE-14549:
---------------------------------------
OK... I get it now. In KeyValueHeap we always have the top scanner removed from
the heap and store in this.current.
In the case of a scanner stack reset, which used to be the top scanner may no
longer be and we would have to put it back on the heap and pull a new top
scanner out, but we have no way of knowing that.
I.e. the top StoreScanner in the RegionScanner's KeyValueHeap might have
changed without notice.
This all looks a bit brittle. What if _other_ StoreScanners (other than the top
scanner) change their peek-element? We'd have to remove and re-add to the
RegionScanner's heap as well... I think. Seems the correct way would be to
reset the RegionScanner stack whenever any of the stores have been compacted.
That would also naturally coarsen the lock to RegionScanner, but the
RegionScanner may not have all the information to reset all StoreScanners.
Tricky...
> Simplify scanner stack reset logic
> ----------------------------------
>
> Key: HBASE-14549
> URL: https://issues.apache.org/jira/browse/HBASE-14549
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Attachments: 14549-0.98.txt
>
>
> Looking at the code, I find that the logic is unnecessarily complex.
> We indicate in updateReaders that the scanner stack needs to be reset. Then
> almost all store scanner (and derived classes) methods need to check and
> actually reset the scanner stack.
> Compaction are rare, we should reset the scanner stack in update readers, and
> hence avoid needing to check in all methods.
> Patch forthcoming.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
