[ https://issues.apache.org/jira/browse/HBASE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121147#comment-13121147 ]
Li Pi commented on HBASE-4482: ------------------------------ After applying patch v2. Current status is, It is very difficult to reproduce the bug. Ted Yu has a stacktrace. The interested bit I posted to http://pastebin.com/Xj6bdFMs. The SlabCache maintains an invariant: that SlabCache and SingleSlabCache, will, in steady state, either both have an entry or neither of them have an entry. In order to maintain this invariant, SlabCache does a few things. For any given caching operation, SlabCache will write to its backingStore EXACTLY once. If an entry already exists. This is why theres this loop here: while (backingStore.putIfAbsent(blockName, scache) != null); (I should put a thread.yield() in here). SlabCache cannot remove an entry from its backingStore unless a SingleSizeCache calls its onEviction. SingleSizeCache will only call onEviction once and only once for any given key. This is enforced with a synchronize block. Once onEviction is called, SlabCache will remove one, and EXACTLY one entry. It will loop until it does this. while ((backingStore.remove(key)) == null) { Thread.yield(); } > Race Condition Concerning Eviction in SlabCache > ----------------------------------------------- > > Key: HBASE-4482 > URL: https://issues.apache.org/jira/browse/HBASE-4482 > Project: HBase > Issue Type: Sub-task > Reporter: Li Pi > Assignee: Li Pi > Priority: Blocker > Fix For: 0.92.0 > > Attachments: hbase-4482v1.txt, hbase-4482v2.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira