Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Message-ID: <850326287.1254163276048.JavaMail.jira@brutus>
Date: Mon, 28 Sep 2009 11:41:16 -0700 (PDT)
From: "Suresh Srinivas (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Subject: [jira] Commented: (HDFS-642) Support pipeline close and close
 recovery
In-Reply-To: <425964827.1253657416059.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760330#action_12760330 ] 

Suresh Srinivas commented on HDFS-642:
--------------------------------------

# Some of the changed code goes beyond 80 chars
# DFSClient.java - can the following check be made in a separate method {{(!streamerClosed && !hasError && clientRunning)}}
# DFSClient.java - waiting for ack (ack size to become zero) can become a separate method
# DFSClient readChunk() - {{( dataLen <= 0 && !lastPacketInBlock )}} should the first part be just datalen == 0?
# DFSClient.Packet - An optimization that could be made in future is to not to allocate any memory to Packet.buf for zero length packet
# Nit: FSDatasetInterface.java - Change comment {and returns the meta info of the replica} to {and return ...}
# DFSClient.java not sure why the waiting for ack queue to become zero len was moved out of previous try catch?


> Support pipeline close and close recovery
> -----------------------------------------
>
>                 Key: HDFS-642
>                 URL: https://issues.apache.org/jira/browse/HDFS-642
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>            Reporter: Hairong Kuang
>            Assignee: Hairong Kuang
>             Fix For: Append Branch
>
>         Attachments: closePipeline.patch
>
>
> This jira intends to implement the third stage of block construction: close. The main ideas are:
> 1. A client notifies the datanodes in the pipeline to finalize a replica and then shuts down the pipeline by sending a special end-of-block message.
> 2. The end-of-block message does not get sent until the client finishes sending all packets belong to the block and have received all their acks.
> 3. If close fails, the client recovers the failures by setting up a new pipeline with the remaining datanodes and a newer generation stamp.
> 4. I plan to use an empty packet as the end-of-block message.

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