[
https://issues.apache.org/jira/browse/HBASE-18375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16092819#comment-16092819
]
Anastasia Braginsky commented on HBASE-18375:
---------------------------------------------
bq. Also the change in CompactionPipeline of removing and adding the last, now
being done at the beginning is it intentional to avoid the NPE bug?
The change in CompactionPipeline is in reversing the order of closing the
suffix and disconnecting the suffix from the compaction pipeline. This problem
wasn't seen, but generally it is correct to close the suffix AFTER it was
already disconnected from pipeline. When the suffix is closed before
disconnected from pipeline, the following problem can happen:
1. Segment is closed, assuming the reference count is zero, segment's chunks
are released.
2. While the segment is still in the compaction pipeline, but after the chunks
are released, scan appears and gets the reference to the segment.
3. The segment is disconnected from pipeline, but scan is accessing the
released chunks... :(
> 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
> 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
>
>
> 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)
