Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 5 Jul 2016 19:06:11 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12986913.1467744768000.28908.1467745571112@Atlassian.JIRA>
In-Reply-To: <JIRA.12986913.1467744768000@Atlassian.JIRA>
References: <JIRA.12986913.1467744768000@Atlassian.JIRA> <JIRA.12986913.1467744768521@arcas>
Subject: [jira] [Updated] (HBASE-16176) Bug fixes/improvements on
 HBASE-15650 Remove TimeRangeTracker as point of contention when many
 threads reading a StoreFile
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 05 Jul 2016 19:06:13 -0000


     [ https://issues.apache.org/jira/browse/HBASE-16176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-16176:
--------------------------
    Status: Patch Available  (was: Open)

> Bug fixes/improvements on HBASE-15650 Remove TimeRangeTracker as point of contention when many threads reading a StoreFile
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-16176
>                 URL: https://issues.apache.org/jira/browse/HBASE-16176
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance
>            Reporter: stack
>            Assignee: stack
>             Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.21
>
>         Attachments: HBASE-16176.branch-1.3.001.patch, HBASE-16176.branch-1.3.002.patch
>
>
> Debugging the parent issue, came up with some improvements on old HBASE-15650 "Remove TimeRangeTracker as point of contention when many threads reading a StoreFile". Lets get them in. Here are the changes:
> {code}
>   6      Change HFile Writer constructor so we pass in the TimeRangeTracker, if one,
>   7      on construction rather than set later (the flag and reference were not
>   8      volatile so could have made for issues in concurrent case) 2. Make sure the
>   9      construction of a TimeRange from a TimeRangeTracer on open of an HFile Reader
>  10      never makes a bad minimum value, one that would preclude us reading any
>  11      values from a file (add a log and set min to 0)
>  12     M hbase-common/src/main/java/org/apache/hadoop/hbase/io/TimeRange.java
>  13      Call through to next constructor (if minStamp was 0, we'd skip setting allTime=true)
>  14     M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
>  15      Add constructor override that takes a TimeRangeTracker (set when flushing but
>  16      not when compacting)
>  17     M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
>  18      Add override creating an HFile in tmp that takes a TimeRangeTracker
>  19     M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java
>  20      Add override for HFile Writer that takes a TimeRangeTracker
>  21      Take it on construction instead of having it passed by a setter later (flags
>  22      and reference set by the setter were not volatile... could have been prob
>  23      in concurrent case)
>  24     M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/TimeRangeTracker.java
>  25      Log WARN if bad initial TimeRange value (and then 'fix' it)
>  26     M hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestTimeRangeTracker.java
>  27      A few tests to prove serialization works as expected and that we'll get a bad min if
>  28      not constructed properly.
> {code}


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