Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <801628467.1218466664818.JavaMail.jira@brutus>
Date: Mon, 11 Aug 2008 07:57:44 -0700 (PDT)
From: "Sebastien Rainville (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-810) Prevent temporary deadlocks when,
 during a scan with write operations, the region splits
In-Reply-To: <1671905493.1218244604398.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sebastien Rainville commented on HBASE-810:
-------------------------------------------

What's the most problematic about this issue is that if we're in the context of a map/reduce job and that a map task fails when a split occurs then when the task is restarted it will only scan the rows in the resulting first region... simply because the input of a hbase map/reduce job is split based on the regions. Actually, is it a bigger problem that could be the consequence of other *normal* failures in a map task?


> Prevent temporary deadlocks when, during a scan with write operations, the region splits
> ----------------------------------------------------------------------------------------
>
>                 Key: HBASE-810
>                 URL: https://issues.apache.org/jira/browse/HBASE-810
>             Project: Hadoop HBase
>          Issue Type: Bug
>    Affects Versions: 0.2.0
>            Reporter: Jean-Daniel Cryans
>            Priority: Minor
>             Fix For: 0.2.1, 0.3.0
>
>
> HBASE-804 was not about the good problem, this one is. Anyone that iterates through the results of a scanner and that rewrites data back into the row at each iteration will hit a UnknownScannerException if a split occurs. See the stack in the referred jira. Timeline :
> Split occurs, acquires a write lock and waits for scanners to finish
> The scanner in the custom code iterates and writes data until the write is blocked by the lock
> deadlock
> The scanner timeouts thus the region splits but the USE will be thrown when next() is called
> Inside a Map, the task will simply be retried when the first one fails. Elsewhere, it becomes more complicated.

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