You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2016/08/17 21:34:20 UTC

[jira] [Commented] (HBASE-16440) MemstoreChunkPool might cross its maxCount of chunks to pool

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

stack commented on HBASE-16440:
-------------------------------

MemstoreLABChunk has a lot of Chunk in it. You don't want to subclass? Seems same except for isPooled. You don't want to add support for this to the base Chunk class? Chunk is a nice name (smile). The method to get one of these things is getChunk.

In getChunk, you have three returns throughout the method. You don't want to just have one on the end?

Otherwise patch looks good. Any chance of a test that can repro the scenario you describe above?

Nice [~anoop.hbase]







> MemstoreChunkPool might cross its maxCount of chunks to pool
> ------------------------------------------------------------
>
>                 Key: HBASE-16440
>                 URL: https://issues.apache.org/jira/browse/HBASE-16440
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>         Attachments: HBASE-16440.patch
>
>
> {code}
> void putbackChunks(BlockingQueue<Chunk> chunks) {
>     int maxNumToPutback = this.maxCount - reclaimedChunks.size();
>     if (maxNumToPutback <= 0) {
>       return;
>     }
>     chunks.drainTo(reclaimedChunks, maxNumToPutback);
>     // clear reference of any non-reclaimable chunks
>     if (chunks.size() > 0) {
>       if (LOG.isTraceEnabled()) {
>         LOG.trace("Left " + chunks.size() + " unreclaimable chunks, removing them from queue");
>       }
>       chunks.clear();
>     }
>   }
> {code}
> There is no synchroization. 2 threads might be calling this API as part of a MSLAB close. (Once the memstore is flushed). It pass all the chunks used by it.  (Those might  not have been come from pool also).  We try to put back chunks such that it is not crossing maxCount.   Suppose maxCount is 10 and currently no chunks in 'reclaimedChunks'. Say both threads at line one. Both see 'maxNumToPutback ' as 10 and that will make 20 chunks being pooled.  Similar issue is in putbackChunk(Chunk chunk) API also.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)