Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <16083057.32661276207693616.JavaMail.jira@thor>
Date: Thu, 10 Jun 2010 18:08:13 -0400 (EDT)
From: "Todd Lipcon (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Subject: [jira] Updated: (HBASE-2670) Reader atomicity broken in trunk and
 branch
In-Reply-To: <10733183.195991275713155142.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Todd Lipcon updated HBASE-2670:
-------------------------------

    Attachment: hbase-2670.txt

It turns out that the majority of this issue was that the comparator used by MemStore didn't take into account the "memstore logical timestamp" (memstoreTS). Thus, a new writer could overwrite older entries if it did a write in the same millisecond. A concurrent reader would then see a partial row because the new entries would be invisible, thus "revealing" cells with a lower "real" TS.

This patch adds two tests to TestMemStore that check for the correct behavior.

I believe there is still a separate issue with multi-row scans and updateReaders(), but I'll open a separate JIRA with separate tests for that one.

> Reader atomicity broken in trunk and branch
> -------------------------------------------
>
>                 Key: HBASE-2670
>                 URL: https://issues.apache.org/jira/browse/HBASE-2670
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.20.5, 0.21.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Blocker
>         Attachments: hbase-2670.txt
>
>
> There appears to be a bug in HBASE-2248 as committed to trunk. See following failing test:
> http://hudson.zones.apache.org/hudson/job/HBase-TRUNK/1296/testReport/junit/org.apache.hadoop.hbase/TestAcidGuarantees/testAtomicity/
> Think this is the same bug we saw early on in 2248 in the 0.20 branch, looks like the fix didn't make it over.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.