hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17434) New Synchronization Scheme for Compaction Pipeline
Date Mon, 09 Jan 2017 13:20:58 GMT

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

Ted Yu commented on HBASE-17434:

bq. Then HBASE-17434 was opened to totally change the synchronization scheme of the compaction

The above doesn't reflect the relationship between this JIRA and HBASE-17379
See my first comment above:

bq. The file downloaded from review board is HBASE-17379-V01.patch

It is very clear why the change here was first proposed.
The copy on write scheme was first introduced by HBASE-17379. IMHO there is no need to open
a second JIRA for variant of copy on write scheme. Discussion should continue on HBASE-17379

> New Synchronization Scheme for Compaction Pipeline
> --------------------------------------------------
>                 Key: HBASE-17434
>                 URL: https://issues.apache.org/jira/browse/HBASE-17434
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Eshcar Hillel
>            Assignee: Eshcar Hillel
>         Attachments: HBASE-17434-V01.patch, HBASE-17434-V02.patch, HBASE-17434-V03.patch
> A new copyOnWrite synchronization scheme is introduced for the compaction pipeline.
> The new scheme is better since it removes the lock from getSegments() which is invoked
in every get and scan operation, and it reduces the number of LinkedList objects that are
created at runtime, thus can reduce GC (not by much, but still...).
> In addition, it fixes the method getTailSize() in compaction pipeline. This method creates
a MemstoreSize object which comprises the data size and the overhead size of the segment and
needs to be atomic.

This message was sent by Atlassian JIRA

View raw message