Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 21 Jun 2013 18:24:21 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12651914.1370771660293.156483.1371839061761@arcas>
In-Reply-To: <JIRA.12651914.1370771660293@arcas>
References: <JIRA.12651914.1370771660293@arcas>
Subject: [jira] [Commented] (HBASE-8721) Deletes can mask puts that happen
 after the delete
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Lars Hofhansl commented on HBASE-8721:
--------------------------------------

I would change the -1 to a -0 if:
# we make this configurable
# the code the changes are not too messy (i.e. no if statements littered everywhere)
# this is carefully tested with all features mentioned above

Then we'd have 3 -0's.

Even the "major compaction glitch" is only an issue when the client messes with timestamps (or regions are moved between RSs and clocks that are wildly out of sync).
As mentioned above there is a proposed solution in form of a long TTL for delete markers, but that will only work if the timestamps represent wall clock time (otherwise "TTL" is meaning less).
                
> Deletes can mask puts that happen after the delete
> --------------------------------------------------
>
>                 Key: HBASE-8721
>                 URL: https://issues.apache.org/jira/browse/HBASE-8721
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: Feng Honghua
>         Attachments: HBASE-8721-0.94-V0.patch
>
>
> this fix aims for bug mentioned in http://hbase.apache.org/book.html 5.8.2.1:
> "Deletes mask puts, even puts that happened after the delete was entered. Remember that a delete writes a tombstone, which only disappears after then next major compaction has run. Suppose you do a delete of everything <= T. After this you do a new put with a timestamp <= T. This put, even if it happened after the delete, will be masked by the delete tombstone. Performing the put will not fail, but when you do a get you will notice the put did have no effect. It will start working again after the major compaction has run. These issues should not be a problem if you use always-increasing versions for new puts to a row. But they can occur even if you do not care about time: just do delete and put immediately after each other, and there is some chance they happen within the same millisecond."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira