[
https://issues.apache.org/jira/browse/HBASE-16372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ramkrishna.s.vasudevan updated HBASE-16372:
-------------------------------------------
Attachment: HBASE-16372_3.patch
Patch for trunk.
On the read side after discussion, have ensured that every time on a shipped
call we do a copy of all the cells that are used in read path as state
variables (in StoreScanner, SQM and CT).
Similarly the Write path also now adds a CellSink to all the Writers which is
of type Shipper. So when the compactor calls shipped on the KVScanner we do
call shipped() on all the writers. Thus copying all the CElls in the write path.
> References to previous cell in read path should be avoided
> ----------------------------------------------------------
>
> Key: HBASE-16372
> URL: https://issues.apache.org/jira/browse/HBASE-16372
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Affects Versions: 2.0.0
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-16372_1.patch, HBASE-16372_2.patch,
> HBASE-16372_3.patch, HBASE-16372_testcase.patch, HBASE-16372_testcase_1.patch
>
>
> Came as part of review discussion in HBASE-15554. If there are references
> kept to previous cells in the read path, with the Ref count based eviction
> mechanism in trunk, then chances are there to evict a block backing the
> previous cell but the read path still does some operations on that garbage
> collected previous cell leading to incorrect results.
> Areas to target
> -> Storescanner
> -> Bloom filters (particularly in compaction path)
> Thanks to [~anoop.hbase] to point out this in bloomfilter path. But we found
> it could be in other areas also.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
