[
https://issues.apache.org/jira/browse/HBASE-26494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-26494:
------------------------------
Fix Version/s: 2.5.0
3.0.0-alpha-3
Hadoop Flags: Reviewed
Resolution: Fixed
Status: Resolved (was: Patch Available)
Pushed to branch-2.5+.
Thanks [~comnetwork] for contributing.
> Using RefCnt to fix the flawed MemStoreLABImpl
> ----------------------------------------------
>
> Key: HBASE-26494
> URL: https://issues.apache.org/jira/browse/HBASE-26494
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 3.0.0-alpha-2, 2.4.9
> Reporter: chenglei
> Assignee: chenglei
> Priority: Major
> Fix For: 2.5.0, 3.0.0-alpha-3
>
>
> As HBASE-26465 said, reference count implementation in {{MemStoreLABImpl}}
> is flawed because its checking and increasing or decreasing is not done in
> atomicity and it ignores state checking when there is illegal state in
> reference count(eg. increasing or decreasing when the resource is already
> freed) , just as following {{incScannerCount}} and {{decScannerCount}}
> methods illustrated, and this flawed implementation has shield the bugs
> HBASE-26465 and HBASE-26488.
> {code:java}
> public void incScannerCount() {
> this.openScannerCount.incrementAndGet();
> }
> public void decScannerCount() {
> int count = this.openScannerCount.decrementAndGet();
> if (this.closed.get() && count == 0) {
> recycleChunks();
> }
> }
> {code}
> We could Introduce {{RefCnt}} into {{MemStoreLABImpl}} to replace its flawed
> reference count implementation, so checking and increasing or decreasing is
> done in atomicity and if there is illegal state in reference count, it would
> throw exception rather than continue using the corrupt data to cause some
> subtle bugs, and meanwhile, the code is more simpler.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
