[
https://issues.apache.org/jira/browse/HBASE-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714932#action_12714932
]
Jonathan Gray commented on HBASE-1460:
--------------------------------------
That is excellent news re: external synchronization on the block index.
Yeah, I'm not sure how we weave in-memory into the system (really just telling
the cache). It seems preferable to keep the cache as dumb as possible (all
information passed in to it rather than it knowing anything about the schema or
stores).
I'm working on unit tests for this now. After I've got it tested we can decide
on how to extend the interface, for now I'm just adding one extra method:
{{public void cacheBlock(String blockName, ByteBuffer buf, boolean inMemory)}}
The existing method will remain and default to inMemory=false.
> Concurrent LRU Block Cache
> --------------------------
>
> Key: HBASE-1460
> URL: https://issues.apache.org/jira/browse/HBASE-1460
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: io
> Reporter: Jonathan Gray
> Assignee: Jonathan Gray
> Fix For: 0.20.0
>
> Attachments: HBASE-1460-v1.patch
>
>
> The LRU-based block cache that will be committed in HBASE-1192 is thread-safe
> but contains a big lock on the hash map. Under high load, the block cache
> will be hit very heavily from a number of threads, so it needs to be built to
> handle massive concurrency.
> This issue aims to implement a new block cache with LRU eviction, but backed
> by a ConcurrentHashMap and a separate eviction thread. Influence will be
> drawn from Solr's ConcurrentLRUCache, however there are major differences
> because solr treats all cached elements as equal size whereas we are
> dependent on our HeapSize interface with realistic (though approximate) heap
> usage.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
