Hadoop Common
  1. Hadoop Common
  2. HADOOP-5146

LocalDirAllocator misses files on the local filesystem

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.20.0
    • Fix Version/s: 0.19.2, 0.20.0
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      For some reason the LocalDirAllocator.getLocaPathToRead doesn't find files which are present, extra logging shows:

      2009-01-30 06:43:32,312 INFO org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext: in ifExists, /grid/2/arunc/mapred-local/taskTracker/archive/xxx.yyy.com/tera/in/_partition.lst exists
      2009-01-30 06:43:32,389 WARN org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext: in getLocalPathToRead, taskTracker/archive/xxx.yyy.com/tera/in/_partition.lst doesn't exist
      2009-01-30 06:43:32,390 WARN org.apache.hadoop.mapred.TaskRunner: attempt_200901300512_0007_m_000055_0 Child Error
       org.apache.hadoop.util.DiskChecker$DiskErrorException: Could not find taskTracker/archive/xx.yyy.com/tera/in/_partition.lst in any of the configured local directories
               at org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.getLocalPathToRead(LocalDirAllocator.java:388)
               at org.apache.hadoop.fs.LocalDirAllocator.getLocalPathToRead(LocalDirAllocator.java:138)
               at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:172)
      
      1. 5146_20090204job.output.txt
        4 kB
        Tsz Wo Nicholas Sze
      2. 5146.patch
        2 kB
        Devaraj Das
      3. 5146.patch
        5 kB
        Devaraj Das
      4. localdirallocator.patch
        7 kB
        Devaraj Das
      5. localdirallocator.patch
        2 kB
        Devaraj Das

        Activity

        Arun C Murthy created issue -
        Hide
        Devaraj Das added a comment -

        Arun, can you please apply this debug patch and let me know what you see in the TT logs around the time a task fails with the DiskErrorException.

        Show
        Devaraj Das added a comment - Arun, can you please apply this debug patch and let me know what you see in the TT logs around the time a task fails with the DiskErrorException.
        Devaraj Das made changes -
        Field Original Value New Value
        Attachment localdirallocator.patch [ 12399099 ]
        Hide
        Devaraj Das added a comment -

        I think I found the cause of this. Basically there is a race condition in TaskRunner where the distributed cache files are localized. Multiple TaskRunner threads may end up trying to localize the same files. The attached patch prevents this from happening. Arun, could you please take a shot at this? Thanks!

        Show
        Devaraj Das added a comment - I think I found the cause of this. Basically there is a race condition in TaskRunner where the distributed cache files are localized. Multiple TaskRunner threads may end up trying to localize the same files. The attached patch prevents this from happening. Arun, could you please take a shot at this? Thanks!
        Devaraj Das made changes -
        Attachment localdirallocator.patch [ 12399202 ]
        Devaraj Das made changes -
        Assignee Devaraj Das [ devaraj ]
        Hide
        Tsz Wo Nicholas Sze added a comment -

        There is a DiskErrorException (and so the job failed) when we run the sample programs such as PiEstimator.

        org.apache.hadoop.util.DiskChecker$DiskErrorException: Could not find taskTracker/pids/attempt_200902021632_0001_m_000002_0 in any of the configured local directories
        	at org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.getLocalPathToRead(LocalDirAllocator.java:381)
        	at org.apache.hadoop.fs.LocalDirAllocator.getLocalPathToRead(LocalDirAllocator.java:138)
        	at org.apache.hadoop.mapred.TaskTracker.getPidFilePath(TaskTracker.java:430)
        	at org.apache.hadoop.mapred.TaskTracker.removePidFile(TaskTracker.java:440)
        	at org.apache.hadoop.mapred.JvmManager$JvmManagerForType$JvmRunner.runChild(JvmManager.java:370)
        	at org.apache.hadoop.mapred.JvmManager$JvmManagerForType$JvmRunner.run(JvmManager.java:338)
        

        (I have changed TaskTracker line 432 to print out the trace.)

        Show
        Tsz Wo Nicholas Sze added a comment - There is a DiskErrorException (and so the job failed) when we run the sample programs such as PiEstimator. org.apache.hadoop.util.DiskChecker$DiskErrorException: Could not find taskTracker/pids/attempt_200902021632_0001_m_000002_0 in any of the configured local directories at org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.getLocalPathToRead(LocalDirAllocator.java:381) at org.apache.hadoop.fs.LocalDirAllocator.getLocalPathToRead(LocalDirAllocator.java:138) at org.apache.hadoop.mapred.TaskTracker.getPidFilePath(TaskTracker.java:430) at org.apache.hadoop.mapred.TaskTracker.removePidFile(TaskTracker.java:440) at org.apache.hadoop.mapred.JvmManager$JvmManagerForType$JvmRunner.runChild(JvmManager.java:370) at org.apache.hadoop.mapred.JvmManager$JvmManagerForType$JvmRunner.run(JvmManager.java:338) (I have changed TaskTracker line 432 to print out the trace.)
        Hide
        Tsz Wo Nicholas Sze added a comment -

        I forgot to say that the sample programs still fail after applied localdirallocator.patch.

        Show
        Tsz Wo Nicholas Sze added a comment - I forgot to say that the sample programs still fail after applied localdirallocator.patch.
        Hide
        Vinod Kumar Vavilapalli added a comment -

        Nicholas, is this problem reproducible? From the code, it seems that the exception you pointed out should not cause tasks/job to fail. Is there a possibility of anything else happening here, something like a disk failure?

        Show
        Vinod Kumar Vavilapalli added a comment - Nicholas, is this problem reproducible? From the code, it seems that the exception you pointed out should not cause tasks/job to fail. Is there a possibility of anything else happening here, something like a disk failure?
        Hide
        Tsz Wo Nicholas Sze added a comment -

        > Nicholas, is this problem reproducible? From the code, it seems that the exception you pointed out should not cause tasks/job to fail.

        Yes, this can be reporduced deterministically in Windows. It seems that this is not a problem in Linux.

        > Is there a possibility of anything else happening here, something like a disk failure?

        No, the disk is working fine.

        5146_20090204job.output.txt: the output for running PiEstimator.

        Show
        Tsz Wo Nicholas Sze added a comment - > Nicholas, is this problem reproducible? From the code, it seems that the exception you pointed out should not cause tasks/job to fail. Yes, this can be reporduced deterministically in Windows. It seems that this is not a problem in Linux. > Is there a possibility of anything else happening here, something like a disk failure? No, the disk is working fine. 5146_20090204job.output.txt: the output for running PiEstimator.
        Tsz Wo Nicholas Sze made changes -
        Attachment 5146_20090204job.output.txt [ 12399467 ]
        Hide
        Ravi Gummadi added a comment -

        pid files seem to be not getting created on cygwin. Could be because shell command "echo $$ >pidFile" seem to be getting the wrong path of pidFile. Looking into the issue.

        Show
        Ravi Gummadi added a comment - pid files seem to be not getting created on cygwin. Could be because shell command "echo $$ >pidFile" seem to be getting the wrong path of pidFile. Looking into the issue.
        Hide
        Amareshwari Sriramadasu added a comment -

        Nicholas, can you try to rerun your example with latest trunk once and see if the problem still exists, because HADOOP-4759 moved pidFile to task directory.

        Show
        Amareshwari Sriramadasu added a comment - Nicholas, can you try to rerun your example with latest trunk once and see if the problem still exists, because HADOOP-4759 moved pidFile to task directory.
        Hide
        Vinod Kumar Vavilapalli added a comment -

        Ravi and I could reproduce the problem locally on a Windows box. The reason for the error is that pid files are not being created on Windows at all due to path problems. The situation persists irrespective of HADOOP-4759. This will be tracked in a new JIRA. The present jira should address the original problem that Arun reported.

        Show
        Vinod Kumar Vavilapalli added a comment - Ravi and I could reproduce the problem locally on a Windows box. The reason for the error is that pid files are not being created on Windows at all due to path problems. The situation persists irrespective of HADOOP-4759 . This will be tracked in a new JIRA. The present jira should address the original problem that Arun reported.
        Hide
        Tsz Wo Nicholas Sze added a comment -

        The problem still exist in Windows. I filed HADOOP-5194. Thanks, Amareshwari, Ravi and Vinod for checking this.

        Show
        Tsz Wo Nicholas Sze added a comment - The problem still exist in Windows. I filed HADOOP-5194 . Thanks, Amareshwari, Ravi and Vinod for checking this.
        Hide
        Devaraj Das added a comment -

        Attaching a patch with the logs removed.

        Show
        Devaraj Das added a comment - Attaching a patch with the logs removed.
        Devaraj Das made changes -
        Attachment 5146.patch [ 12400740 ]
        Hide
        Devaraj Das added a comment -

        After some analysis, found the cause of the race condition:
        1) Assume a fresh hdfs cluster with no files. Run a job (foo) that generates a file in the hdfs called partition.lst
        2) Run a job (bar) that uses the file foo generated. On a given node, one task localizes partition.lst in the dist cache and other tasks simply use this
        3) bar job finishes successfully without any task failures....
        4) Now run foo again. This will regenerate the file partition.lst at the same location.
        5) Run bar again. On a given node that was used by the previous bar job, a task t1 from the new bar job will still find the partition.lst in the cache in ifExists() check. Context now switches to another taskrunner thread, say t2 of the new bar job.
        6) t2 also finds that ifExists() returns true but when it does getLocalCache, it finds the file to be stale (since the file got regenerated in the foo job again) and deletes it in DistributedCache.localizeCache. Context now switches back to t1.
        7) t1 does getLocalPathToRead and doesn't find the file... For t1, this is a situation where ifExists() returns true, but getLocalPathToRead returns false for the same path. This is the race condition..

        The attached patch removes the call to ifExists/getLocalPathToRead in the TaskRunner thread during the cache localization. It always does getLocalPathForWrite. In the case where the file is already localized, the path returned by getLocalPathForWrite will not be used and instead getLocalCache will return the already localized path.

        Show
        Devaraj Das added a comment - After some analysis, found the cause of the race condition: 1) Assume a fresh hdfs cluster with no files. Run a job (foo) that generates a file in the hdfs called partition.lst 2) Run a job (bar) that uses the file foo generated. On a given node, one task localizes partition.lst in the dist cache and other tasks simply use this 3) bar job finishes successfully without any task failures.... 4) Now run foo again. This will regenerate the file partition.lst at the same location. 5) Run bar again. On a given node that was used by the previous bar job, a task t1 from the new bar job will still find the partition.lst in the cache in ifExists() check. Context now switches to another taskrunner thread, say t2 of the new bar job. 6) t2 also finds that ifExists() returns true but when it does getLocalCache, it finds the file to be stale (since the file got regenerated in the foo job again) and deletes it in DistributedCache.localizeCache. Context now switches back to t1. 7) t1 does getLocalPathToRead and doesn't find the file... For t1, this is a situation where ifExists() returns true, but getLocalPathToRead returns false for the same path. This is the race condition.. The attached patch removes the call to ifExists/getLocalPathToRead in the TaskRunner thread during the cache localization. It always does getLocalPathForWrite. In the case where the file is already localized, the path returned by getLocalPathForWrite will not be used and instead getLocalCache will return the already localized path.
        Devaraj Das made changes -
        Attachment 5146.patch [ 12401022 ]
        Devaraj Das made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Hide
        Vinod Kumar Vavilapalli added a comment -

        The explanation for the race condition scenario sounds correct. The patch looks good too. +1

        Show
        Vinod Kumar Vavilapalli added a comment - The explanation for the race condition scenario sounds correct. The patch looks good too. +1
        Devaraj Das made changes -
        Component/s mapred [ 12310690 ]
        Hide
        Amareshwari Sriramadasu added a comment -

        Patch looks good to me too. And also validated the patch over terasort runs
        test-patch result:

             [exec]
             [exec] -1 overall.
             [exec]
             [exec]     +1 @author.  The patch does not contain any @author tags.
             [exec]
             [exec]     -1 tests included.  The patch doesn't appear to include any new or modified tests.
             [exec]                         Please justify why no tests are needed for this patch.
             [exec]
             [exec]     +1 javadoc.  The javadoc tool did not generate any warning messages.
             [exec]
             [exec]     +1 javac.  The applied patch does not increase the total number of javac compiler warnings.
             [exec]
             [exec]     +1 findbugs.  The patch does not introduce any new Findbugs warnings.
             [exec]
             [exec]     +1 Eclipse classpath. The patch retains Eclipse classpath integrity.
             [exec]
             [exec]     +1 release audit.  The applied patch does not increase the total number of release audit warnings.
             [exec]
        

        ant tests passed on my machine.

        Show
        Amareshwari Sriramadasu added a comment - Patch looks good to me too. And also validated the patch over terasort runs test-patch result: [exec] [exec] -1 overall. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no tests are needed for this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs warnings. [exec] [exec] +1 Eclipse classpath. The patch retains Eclipse classpath integrity. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] ant tests passed on my machine.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12401022/5146.patch
        against trunk revision 748403.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no tests are needed for this patch.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 Eclipse classpath. The patch retains Eclipse classpath integrity.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        -1 core tests. The patch failed core unit tests.

        -1 contrib tests. The patch failed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta/10/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta/10/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta/10/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta/10/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12401022/5146.patch against trunk revision 748403. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. -1 contrib tests. The patch failed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta/10/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta/10/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta/10/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta/10/console This message is automatically generated.
        Hide
        Amareshwari Sriramadasu added a comment -

        I think -1 for core and contrib tests is due to downtime in the svn. I'm not able to view the testReport or even console output.
        Giri, can you please confirm?

        As I commented earlier All tests passed on my machine.

        Show
        Amareshwari Sriramadasu added a comment - I think -1 for core and contrib tests is due to downtime in the svn. I'm not able to view the testReport or even console output. Giri, can you please confirm? As I commented earlier All tests passed on my machine.
        Hide
        Amareshwari Sriramadasu added a comment -

        Resubmitting to hudson

        Show
        Amareshwari Sriramadasu added a comment - Resubmitting to hudson
        Amareshwari Sriramadasu made changes -
        Status Patch Available [ 10002 ] Open [ 1 ]
        Amareshwari Sriramadasu made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12401022/5146.patch
        against trunk revision 748628.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no tests are needed for this patch.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 Eclipse classpath. The patch retains Eclipse classpath integrity.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/13/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/13/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/13/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/13/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12401022/5146.patch against trunk revision 748628. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/13/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/13/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/13/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/13/console This message is automatically generated.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12401022/5146.patch
        against trunk revision 748770.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no tests are needed for this patch.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 Eclipse classpath. The patch retains Eclipse classpath integrity.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        -1 contrib tests. The patch failed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/15/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/15/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/15/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/15/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12401022/5146.patch against trunk revision 748770. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. -1 contrib tests. The patch failed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/15/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/15/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/15/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/15/console This message is automatically generated.
        Hide
        Hemanth Yamijala added a comment -

        I just committed this to 0.19.2, 0.20 and trunk. Thanks, Devaraj !

        Show
        Hemanth Yamijala added a comment - I just committed this to 0.19.2, 0.20 and trunk. Thanks, Devaraj !
        Hemanth Yamijala made changes -
        Hadoop Flags [Reviewed]
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Fix Version/s 0.19.2 [ 12313650 ]
        Resolution Fixed [ 1 ]
        Hide
        Hudson added a comment -
        Show
        Hudson added a comment - Integrated in Hadoop-trunk #778 (See http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/778/ )
        Nigel Daley made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Owen O'Malley made changes -
        Component/s mapred [ 12310690 ]

          People

          • Assignee:
            Devaraj Das
            Reporter:
            Arun C Murthy
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development