Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7DCEEBA46 for ; Wed, 4 Jan 2012 10:18:33 +0000 (UTC) Received: (qmail 86102 invoked by uid 500); 4 Jan 2012 10:18:33 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 85468 invoked by uid 500); 4 Jan 2012 10:18:27 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 85439 invoked by uid 99); 4 Jan 2012 10:18:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jan 2012 10:18:25 +0000 X-ASF-Spam-Status: No, hits=-2001.6 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jan 2012 10:18:23 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 7FB6B137409 for ; Wed, 4 Jan 2012 10:17:39 +0000 (UTC) Date: Wed, 4 Jan 2012 10:17:39 +0000 (UTC) From: "Zhihong Yu (Commented) (JIRA)" To: issues@hbase.apache.org Message-ID: <399250066.4111.1325672259525.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1918412762.34095.1324439491031.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (HBASE-5081) Distributed log splitting deleteNode races against splitLog retry MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179394#comment-13179394 ] Zhihong Yu commented on HBASE-5081: ----------------------------------- In the above scenario, would there be many "duplicate log" messages in master log file ? > Distributed log splitting deleteNode races against splitLog retry > ------------------------------------------------------------------ > > Key: HBASE-5081 > URL: https://issues.apache.org/jira/browse/HBASE-5081 > Project: HBase > Issue Type: Bug > Components: wal > Affects Versions: 0.92.0, 0.94.0 > Reporter: Jimmy Xiang > Assignee: Prakash Khemani > Fix For: 0.92.0 > > Attachments: 0001-HBASE-5081-jira-Distributed-log-splitting-deleteNode.patch, 0001-HBASE-5081-jira-Distributed-log-splitting-deleteNode.patch, 0001-HBASE-5081-jira-Distributed-log-splitting-deleteNode.patch, 0001-HBASE-5081-jira-Distributed-log-splitting-deleteNode.patch, distributed-log-splitting-screenshot.png, hbase-5081-patch-v6.txt, hbase-5081-patch-v7.txt, hbase-5081_patch_for_92_v4.txt, hbase-5081_patch_v5.txt, patch_for_92.txt, patch_for_92_v2.txt, patch_for_92_v3.txt > > > Recently, during 0.92 rc testing, we found distributed log splitting hangs there forever. Please see attached screen shot. > I looked into it and here is what happened I think: > 1. One rs died, the servershutdownhandler found it out and started the distributed log splitting; > 2. All three tasks failed, so the three tasks were deleted, asynchronously; > 3. Servershutdownhandler retried the log splitting; > 4. During the retrial, it created these three tasks again, and put them in a hashmap (tasks); > 5. The asynchronously deletion in step 2 finally happened for one task, in the callback, it removed one > task in the hashmap; > 6. One of the newly submitted tasks' zookeeper watcher found out that task is unassigned, and it is not > in the hashmap, so it created a new orphan task. > 7. All three tasks failed, but that task created in step 6 is an orphan so the batch.err counter was one short, > so the log splitting hangs there and keeps waiting for the last task to finish which is never going to happen. > So I think the problem is step 2. The fix is to make deletion sync, instead of async, so that the retry will have > a clean start. > Async deleteNode will mess up with split log retrial. In extreme situation, if async deleteNode doesn't happen > soon enough, some node created during the retrial could be deleted. > deleteNode should be sync. -- 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