[jira] Commented: (HBASE-1460) Concurrent LRU Block Cache

["stack (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714944#action_12714944 ] 

stack commented on HBASE-1460:
------------------------------

CachedBlock needs a class comment as does CachedBlockQueue (Looks like the constructor comment here could serve as the class comment)... and ConcurrentLRUBlockCache

Why this in CachedBlock?

+  public void setBuffer(ByteBuffer buf) {^M
+    this.buf = buf;^M
+  }^M

Can it not be done in constructor?

That align method looks good, like it should be in the bytes or heapsize classes?

When would this be used?

+  public CachedBlock [] get() {^M

Should we remove LRUBlockCache and just rename this ConcurrentLRUBlockCache as LRUBlockCache?  I don't see any point in our keeping up two caches.

Remove the below rather than comment out I'd say:

{code}
+^M
+///**^M
+//* Constructor.^M
+//* @param maxBytes maximum bytes this cache can hold^M
+//* @param conf hbase configuration^M
+//*/^M
{code}

You added a test!!!!  Two of them!!

Patch looks great.

Here are comments carried over from 1192 that were ignored (smile):

+ Can we make block cache size be percentage of heap rather than hard number?  I suppose it means cache needs to be able to grow as heap grows.

> 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.