hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-6334) TestImprovement for TestHRegion.testWritesWhileGetting
Date Thu, 12 Jul 2012 07:00:46 GMT

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

Gregory Chanan updated HBASE-6334:

    Attachment: HBASE-6334-trunk.patch

Attached patch against trunk.  If I get a +1, I'll backport to 0.94 and 0.92 (I already checked,
backports are straightforward).

The basic idea is to be very aggressive about flushing while putting/getting so we can catch
regressions in this area, which has been a trouble spot in the past (see HBASE-2856 and HBASE-4195).
 From my experiments, this consistently catches HBASE-4195 and HBASE-2856 if they are not
applied (e.g. on 0.90 -- see HBASE-6379 for more details on these two issues).

The rest of the patch deals with compactions.  Because the patch is so aggressive with flushes,
it can create many files.  With a standard ulimit (1024) I would occasionally bump against
the open file limit.  Bumping the ulimit fixed the issue, but I don't think this is a good
thing to require for unit tests.  So there is some code to run compactions fairly frequently.
> TestImprovement for TestHRegion.testWritesWhileGetting
> ------------------------------------------------------
>                 Key: HBASE-6334
>                 URL: https://issues.apache.org/jira/browse/HBASE-6334
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.92.1, 0.94.0, 0.96.0
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>            Priority: Minor
>         Attachments: HBASE-6334-trunk.patch
> Two improvements:
> 1. I was running testWritesWhileGetting on 0.90.6 (which lacks HBASE-4195) and I couldn't
get the 20% failures mentioned in the JIRA.  It was more like 1%.  So I increased the flush
frequency and it failed most of the time.
> 2.  The check on failure is wrong:
> {code}
> assertEquals(previousKV.getValue(), thisValue);
> {code}
> Since this is a byte array, we should use Bytes.compareTo.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message