Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 12 Apr 2012 07:20:27 +0000 (UTC)
From: "Konstantin Shvachko (Commented) (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <1961173217.16366.1334215227493.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HDFS-119) logSync() may block NameNode forever.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Konstantin Shvachko commented on HDFS-119:
------------------------------------------

> (nit: the indent seems not aligned)

Yes, I thought that way it is easier to see what the actual changes are. Indentation can be corrected as style change just before the commit.

> removeEditsStreamsAndStorageDirs() could unneceissarily invoke fatalExit()

Good point. Even though it's a theoretical possibility, because removeEditsStreamsAndStorageDirs() is called only in logSync(), when {{isSyncRunning == true}}, so everybody else should be waiting for sync to complete. But people tend to change code and use methods already defined, so let's file a jira.
                
> logSync() may block NameNode forever.
> -------------------------------------
>
>                 Key: HDFS-119
>                 URL: https://issues.apache.org/jira/browse/HDFS-119
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Konstantin Shvachko
>            Assignee: Suresh Srinivas
>             Fix For: 0.21.0
>
>         Attachments: HDFS-119-branch-1.0.patch, HDFS-119.patch, HDFS-119.patch
>
>
> # {{FSEditLog.logSync()}} first waits until {{isSyncRunning}} is false and then performs syncing to file streams by calling {{EditLogOutputStream.flush()}}.
> If an exception is thrown after {{isSyncRunning}} is set to {{true}} all threads will always wait on this condition.
> An {{IOException}} may be thrown by {{EditLogOutputStream.setReadyToFlush()}} or a {{RuntimeException}} may be thrown by {{EditLogOutputStream.flush()}} or by {{processIOError()}}.
> # The loop that calls {{eStream.flush()}} for multiple {{EditLogOutputStream}}-s is not synchronized, which means that another thread may encounter an error and modify {{editStreams}} by say calling {{processIOError()}}. Then the iterating process in {{logSync()}} will break with {{IndexOutOfBoundException}}.

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