[ https://issues.apache.org/jira/browse/HBASE-26494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750929#comment-17750929 ]
Viraj Jasani commented on HBASE-26494: -------------------------------------- probable cause for HBASE-27941? > 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.10#820010)