[
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