Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Date: Tue, 28 Feb 2012 01:03:49 +0000 (UTC)
From: "Siddharth Seth (Commented) (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: 
 <1592178317.25945.1330391029158.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1868269021.25190.1330381909043.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (MAPREDUCE-3931) MR tasks failing due to
 changing timestamps on Resources to download
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Siddharth Seth commented on MAPREDUCE-3931:
-------------------------------------------

This looks like other races we've seen where {{build}} is called on the same Proto builder object by multiple threads. In cases of JobId etc - values would end up getting reset to 0.
This is the same race in the LocalResource object - but the manifestation is more interesting. 2971811411 is 1330116705875 with the MS 4 bytes set to 0. Turns out, assigning to a long in Java may not be atomic.

There's multiple parallel startContainer calls - which access the same LocalReosurce object in the AM - which is where the value can get corrupt. Will attach a patch shortly which adds synchronization to LocalResourcePBImpl.
                
> MR tasks failing due to changing timestamps on Resources to download
> --------------------------------------------------------------------
>
>                 Key: MAPREDUCE-3931
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-3931
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: mrv2
>    Affects Versions: 0.23.0
>            Reporter: Vinod Kumar Vavilapalli
>            Assignee: Siddharth Seth
>             Fix For: 0.23.2
>
>
> [~karams] reported this offline. Seems that tasks are randomly failing during gridmix runs:
> {code}
> 2012-02-24 21:03:34,912 INFO [AsyncDispatcher event handler] org.apache.hadoop.mapreduce.v2.app.job.impl.TaskAttemptImpl: Diagnostics report from attempt_1330116323296_0140_m_003868_0: RemoteTrace:
> java.io.IOException: Resource hdfs://hostname.com:8020/user/hadoop15/.staging/job_1330116323296_0140/job.jar changed on src filesystem (expected 2971811411, was 1330116705875
>        at org.apache.hadoop.yarn.util.FSDownload.copy(FSDownload.java:90)
>        at org.apache.hadoop.yarn.util.FSDownload.access$000(FSDownload.java:49)
>        at org.apache.hadoop.yarn.util.FSDownload$1.run(FSDownload.java:157)
>        at org.apache.hadoop.yarn.util.FSDownload$1.run(FSDownload.java:155)
>        at java.security.AccessController.doPrivileged(Native Method)
>        at javax.security.auth.Subject.doAs(Subject.java:396)
>        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1177)
>        at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:153)
>        at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:49)
>        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>        at java.lang.Thread.run(Thread.java:619)
>  at LocalTrace:
>        org.apache.hadoop.yarn.exceptions.impl.pb.YarnRemoteExceptionPBImpl: Resource hdfs://hostname.com:8020/user/hadoop15/.staging/job_1330116323296_0140/job.jar changed on src filesystem (expected 2971811411, was 1330116705875
>        at org.apache.hadoop.yarn.server.nodemanager.api.protocolrecords.impl.pb.LocalResourceStatusPBImpl.convertFromProtoFormat(LocalResourceStatusPBImpl.java:217)
>        at org.apache.hadoop.yarn.server.nodemanager.api.protocolrecords.impl.pb.LocalResourceStatusPBImpl.getException(LocalResourceStatusPBImpl.java:147)
>        at org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService$LocalizerRunner.update(ResourceLocalizationService.java:827)
>        at org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService$LocalizerTracker.processHeartbeat(ResourceLocalizationService.java:497)
>        at org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService.heartbeat(ResourceLocalizationService.java:222)
>        at org.apache.hadoop.yarn.server.nodemanager.api.impl.pb.service.LocalizationProtocolPBServiceImpl.heartbeat(LocalizationProtocolPBServiceImpl.java:46)
>        at org.apache.hadoop.yarn.proto.LocalizationProtocol$LocalizationProtocolService$2.callBlockingMethod(LocalizationProtocol.java:57)
>        at org.apache.hadoop.yarn.ipc.ProtoOverHadoopRpcEngine$Server.call(ProtoOverHadoopRpcEngine.java:342)
>        at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1493)
>        at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1489)
>        at java.security.AccessController.doPrivileged(Native Method)
>        at javax.security.auth.Subject.doAs(Subject.java:396)
>        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1177)
>        at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1487)
> {code}

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