Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 22 Mar 2012 02:41:25 +0000 (UTC)
From: "Prakash Khemani (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <544094569.709.1332384085136.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <128360593.40139.1332304140996.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5606) SplitLogManger async delete node
 hangs log splitting when ZK connection is lost
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Prakash Khemani commented on HBASE-5606:
----------------------------------------

The getDataSetWatch() call in the timeout-monitor is only being done to check whether the znode still exists or not. If there is a failure in getting to the znode then we should ignore that failure.

How about implementing the following

in timeoutmonitor 
call getDataSetWatch() only if task has not already failed. (This is just an optimization and it can be done without any locking)

for this particular getDataSetWatch() call, store a IGNORE-ZK-ERROR flag in the zk async context. If a zk error happens silently then do nothing.


> SplitLogManger async delete node hangs log splitting when ZK connection is lost 
> --------------------------------------------------------------------------------
>
>                 Key: HBASE-5606
>                 URL: https://issues.apache.org/jira/browse/HBASE-5606
>             Project: HBase
>          Issue Type: Bug
>          Components: wal
>    Affects Versions: 0.92.0
>            Reporter: Gopinathan A
>            Priority: Critical
>             Fix For: 0.92.2
>
>         Attachments: 5606.txt
>
>
> 1. One rs died, the servershutdownhandler found it out and started the distributed log splitting;
> 2. All tasks are failed due to ZK connection lost, so the all the tasks were deleted asynchronously;
> 3. Servershutdownhandler retried the log splitting;
> 4. The asynchronously deletion in step 2 finally happened for new task
> 5. This made the SplitLogManger in hanging state.
> This leads to .META. region not assigened for long time
> {noformat}
> hbase-root-master-HOST-192-168-47-204.log.2012-03-14"(55413,79):2012-03-14 19:28:47,932 DEBUG org.apache.hadoop.hbase.master.SplitLogManager: put up splitlog task at znode /hbase/splitlog/hdfs%3A%2F%2F192.168.47.205%3A9000%2Fhbase%2F.logs%2Flinux-114.site%2C60020%2C1331720381665-splitting%2Flinux-114.site%252C60020%252C1331720381665.1331752316170
> hbase-root-master-HOST-192-168-47-204.log.2012-03-14"(89303,79):2012-03-14 19:34:32,387 DEBUG org.apache.hadoop.hbase.master.SplitLogManager: put up splitlog task at znode /hbase/splitlog/hdfs%3A%2F%2F192.168.47.205%3A9000%2Fhbase%2F.logs%2Flinux-114.site%2C60020%2C1331720381665-splitting%2Flinux-114.site%252C60020%252C1331720381665.1331752316170
> {noformat}
> {noformat}
> hbase-root-master-HOST-192-168-47-204.log.2012-03-14"(80417,99):2012-03-14 19:34:31,196 DEBUG org.apache.hadoop.hbase.master.SplitLogManager$DeleteAsyncCallback: deleted /hbase/splitlog/hdfs%3A%2F%2F192.168.47.205%3A9000%2Fhbase%2F.logs%2Flinux-114.site%2C60020%2C1331720381665-splitting%2Flinux-114.site%252C60020%252C1331720381665.1331752316170
> hbase-root-master-HOST-192-168-47-204.log.2012-03-14"(89456,99):2012-03-14 19:34:32,497 DEBUG org.apache.hadoop.hbase.master.SplitLogManager$DeleteAsyncCallback: deleted /hbase/splitlog/hdfs%3A%2F%2F192.168.47.205%3A9000%2Fhbase%2F.logs%2Flinux-114.site%2C60020%2C1331720381665-splitting%2Flinux-114.site%252C60020%252C1331720381665.1331752316170
> {noformat}

--
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