Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 8 Mar 2014 00:54:46 +0000 (UTC)
From: "Jean-Marc Spaggiari (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12699519.1394230574277.27768.1394240086099@arcas>
In-Reply-To: <JIRA.12699519.1394230574277@arcas>
References: <JIRA.12699519.1394230574277@arcas>
Subject: [jira] [Commented] (HBASE-10702) HBase fails to respect Deletes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jean-Marc Spaggiari commented on HBASE-10702:
---------------------------------------------

deleteColums, deleteColumn, in both cases there is a get just before so it's already all in memory anyway. And this should not really change the delete feature, did it?

If with deleteColumn, we should not be able to get the value we just delete, even more when we have to do that 6 time:
{code}
6265955 Doing a delete for 0000076369 failed. Start to count
puts=102899 deletes=2865 retries=6
{code}
No?

> HBase fails to respect Deletes
> ------------------------------
>
>                 Key: HBASE-10702
>                 URL: https://issues.apache.org/jira/browse/HBASE-10702
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.94.2, 0.94.15, 0.94.17
>            Reporter: Jean-Marc Spaggiari
>            Priority: Critical
>
> One of our user contacted me about an issue with Deletes.
> Some of the deletes they do are not totally processed. Therefore, after the Delete, if they do a Get, from time to time, the Get return the row when it should have been deleted and should have returned nothing. After multiple Deletes, the row is finally deleted. If we don't retry after the 1st attempt, the row stays there. Even after a flush, a major_compact, etc.
> I have been able to reproduce the issue in 0.94.2 (CDH4.2.0 EC2), 0.94.15(CDH4.6.0 EC2) and 0.94.17 (Apache version bare metal)
> Here is a simple output from my test app.
> 1736509 Doing a delete for 0000099676 failed. Start to count
> puts=311 deletes=64 retries=2
> 2281712 Doing a delete for 0000027606 failed. Start to count
> puts=3679 deletes=247 retries=2
> 2388305 Doing a delete for 0000018306 failed. Start to count
> puts=4744 deletes=290 retries=2
> 2532943 Doing a delete for 0000030446 failed. Start to count
> puts=5678 deletes=337 retries=2
> 2551421 Doing a delete for 0000046304 failed. Start to count
> puts=5845 deletes=345 retries=2
> 2561099 Doing a delete for 0000019619 failed. Start to count
> puts=5869 deletes=347 retries=3
> First field is the time in ms since the test started.  So first error occurs after about 30 minutes. Below are the number of puts and deletes done, and the numbers of required retries to get the value deleted.
> Key is random number between  0000000000 and 0000100000.
> Very simple test. Just doing more puts than deletes.
> Tests are running on 0.96.1.1 for almost 1h now so it seems to be fine, but it's not on the same cluster, so I will keep that running for hours/days first.


--
This message was sent by Atlassian JIRA
(v6.2#6252)