[
https://issues.apache.org/jira/browse/HBASE-18375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119635#comment-16119635
]
Anoop Sam John commented on HBASE-18375:
----------------------------------------
bq. If CellChunkMap is requested in hbase-site.xml
("hbase.hregion.compacting.memstore.index"), then StrongMap is going to cover
every chunk.
Otherwise, StrongMap is going to cover only chunks in pool.
Then there will be concern as in HBASE-16195.
It is the ChunkMap impl which need to keep the ref to Chunks for longer. So I
think it should be responsibility of that class to act. Also say we have used
10 chunks till now and then there is an in memory flush/ flatten to
CellChunkMap. Now may be some of the Cells become irrelevant and say only 5
Chunks have active refs from Cell. (Assume all these are Chunk not from pool)
So we can keep only 5 Chunks in the CellChunkImpl.
Need to see what to do where. But if we can do above way that is the best.
> The pool chunks from ChunkCreator are deallocated while in pool because there
> is no reference to them
> -----------------------------------------------------------------------------------------------------
>
> Key: HBASE-18375
> URL: https://issues.apache.org/jira/browse/HBASE-18375
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.0.0-alpha-1
> Reporter: Anastasia Braginsky
> Assignee: Anastasia Braginsky
> Priority: Critical
> Fix For: 2.0.0, 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18375-V01.patch, HBASE-18375-V02.patch,
> HBASE-18375-V03.patch, HBASE-18375-V04.patch
>
>
> Because MSLAB list of chunks was changed to list of chunk IDs, the chunks
> returned back to pool can be deallocated by JVM because there is no reference
> to them. The solution is to protect pool chunks from GC by the strong map of
> ChunkCreator introduced by HBASE-18010. Will prepare the patch today.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
