[jira] Commented: (MAPREDUCE-479) Add reduce ID to shuffle clienttrace
[ https://issues.apache.org/jira/browse/MAPREDUCE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740584#action_12740584 ] Hadoop QA commented on MAPREDUCE-479: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12415747/MAPREDUCE-479-4.patch against trunk revision 801959. +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 new tests are needed for this patch. Also please list what manual steps were performed to verify 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 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/Mapreduce-Patch-vesta.apache.org/453/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-vesta.apache.org/453/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-vesta.apache.org/453/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-vesta.apache.org/453/console This message is automatically generated. Add reduce ID to shuffle clienttrace Key: MAPREDUCE-479 URL: https://issues.apache.org/jira/browse/MAPREDUCE-479 Project: Hadoop Map/Reduce Issue Type: Improvement Affects Versions: 0.21.0 Reporter: Jiaqi Tan Assignee: Jiaqi Tan Priority: Minor Fix For: 0.21.0 Attachments: HADOOP-6013.patch, MAPREDUCE-479-1.patch, MAPREDUCE-479-2.patch, MAPREDUCE-479-3.patch, MAPREDUCE-479-4.patch, MAPREDUCE-479.patch Current clienttrace messages from shuffles note only the destination map ID but not the source reduce ID. Having both source and destination ID of each shuffle enables full tracing of execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-479) Add reduce ID to shuffle clienttrace
[ https://issues.apache.org/jira/browse/MAPREDUCE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12732356#action_12732356 ] Chris Douglas commented on MAPREDUCE-479: - bq. if the system's operation cannot be exposed at all then that greatly detracts from the usability of the system for users. [...] needing to perform time-based + host-based disambiguation of multiple attempts of the same task requires the assumption that the same task will not have multiple attempts being run on the same host, which is even more opaque than maintaining a publicly-documented (i.e. with this JIRA) side-effect. I think you and I differ in our perspectives of users. Even granting the premise that traceability greatly improves diagnosis of system problems, that Hadoop will be less usable to those writing map/reduce programs because it's possible that, someday, someone may write a scheduler that speculatively executes two instances of the same task on the same machine at the same time... does not follow. The point we're debating is not whether tracing is good, but whether including the task attempt ID as a permanent feature of the shuffle protocol is a good tradeoff for map/reduce. The information _is_ available in general, but for near-certainty in this hypothetical situation one needs to examine task logs. That it's easier to collect from the TT logs isn't a good enough reason to impose this on maintainers; expecting them to find its purpose documented in the bug tracking system and retain the property in support of possible downstream processing is not reasonable. Add reduce ID to shuffle clienttrace Key: MAPREDUCE-479 URL: https://issues.apache.org/jira/browse/MAPREDUCE-479 Project: Hadoop Map/Reduce Issue Type: Improvement Affects Versions: 0.21.0 Reporter: Jiaqi Tan Assignee: Jiaqi Tan Priority: Minor Fix For: 0.21.0 Attachments: HADOOP-6013.patch, MAPREDUCE-479-1.patch, MAPREDUCE-479-2.patch, MAPREDUCE-479-3.patch, MAPREDUCE-479.patch Current clienttrace messages from shuffles note only the destination map ID but not the source reduce ID. Having both source and destination ID of each shuffle enables full tracing of execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-479) Add reduce ID to shuffle clienttrace
[ https://issues.apache.org/jira/browse/MAPREDUCE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12732362#action_12732362 ] Jiaqi Tan commented on MAPREDUCE-479: - I would argue that you cannot actually get the information accurately from TT logs; doing that would require the assumption of clock synchronization which is a common enough assumption in academia but in practice does not always hold true. The clienttrace messages are logged on the TT which is serving the map outputs, and are timestamped with the clock of the TT serving the map outputs. But the reduce attempts are running on other TTs, and those log messages that record the running of the reduce attempts are timestamped with the clock of the TT running the reduce. The only way to get ground truth that reflects causality is to pass the reduce attempt ID unless you have a totally ordered global clock in the system. We could get that from the JT, but unfortunately the job history logs for some reason record 0 times for failed attempts. What I'm suggesting is that short of putting the reduce attempt ID in the shuffle protocol, there is no other way of obtaining that information accurately, any other way is subject to assumptions such as clock synchronization or assumptions about the scheduling protocol. Also, in previous versions, the shuffle passed the entire reduce attempt ID in the HTTP request IIRC, so I'm not seeing why that's an issue now to put it back. Add reduce ID to shuffle clienttrace Key: MAPREDUCE-479 URL: https://issues.apache.org/jira/browse/MAPREDUCE-479 Project: Hadoop Map/Reduce Issue Type: Improvement Affects Versions: 0.21.0 Reporter: Jiaqi Tan Assignee: Jiaqi Tan Priority: Minor Fix For: 0.21.0 Attachments: HADOOP-6013.patch, MAPREDUCE-479-1.patch, MAPREDUCE-479-2.patch, MAPREDUCE-479-3.patch, MAPREDUCE-479.patch Current clienttrace messages from shuffles note only the destination map ID but not the source reduce ID. Having both source and destination ID of each shuffle enables full tracing of execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-479) Add reduce ID to shuffle clienttrace
[ https://issues.apache.org/jira/browse/MAPREDUCE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12732391#action_12732391 ] Chris Douglas commented on MAPREDUCE-479: - As I said earlier, if you wanted to replace the reduce parameter with the attempt id- and extract the former from the latter- I wouldn't oppose it. What bothers me is that, other than logging it to the clienttrace on behalf of a possible downstream tool, the parameter serves no functional purpose to map/reduce; it is likely to be optimized away. If you elect to do this, you should also add a comment explaining why the full attempt id is included in the request. Add reduce ID to shuffle clienttrace Key: MAPREDUCE-479 URL: https://issues.apache.org/jira/browse/MAPREDUCE-479 Project: Hadoop Map/Reduce Issue Type: Improvement Affects Versions: 0.21.0 Reporter: Jiaqi Tan Assignee: Jiaqi Tan Priority: Minor Fix For: 0.21.0 Attachments: HADOOP-6013.patch, MAPREDUCE-479-1.patch, MAPREDUCE-479-2.patch, MAPREDUCE-479-3.patch, MAPREDUCE-479.patch Current clienttrace messages from shuffles note only the destination map ID but not the source reduce ID. Having both source and destination ID of each shuffle enables full tracing of execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-479) Add reduce ID to shuffle clienttrace
[ https://issues.apache.org/jira/browse/MAPREDUCE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12732304#action_12732304 ] Jiaqi Tan commented on MAPREDUCE-479: - Traceability greatly improves the ability for diagnosis to be carried out on the system, and I would argue that the ability for the system to be diagnosed is a first-class feature that is important for its own sake; if the system's operation cannot be exposed at all then that greatly detracts from the usability of the system for users. I would still argue for the side-effect to be maintained because needing to perform time-based + host-based disambiguation of multiple attempts of the same task requires the assumption that the same task will not have multiple attempts being run on the same host, which is even more opaque than maintaining a publicly-documented (i.e. with this JIRA) side-effect. Add reduce ID to shuffle clienttrace Key: MAPREDUCE-479 URL: https://issues.apache.org/jira/browse/MAPREDUCE-479 Project: Hadoop Map/Reduce Issue Type: Improvement Affects Versions: 0.21.0 Reporter: Jiaqi Tan Assignee: Jiaqi Tan Priority: Minor Fix For: 0.21.0 Attachments: HADOOP-6013.patch, MAPREDUCE-479-1.patch, MAPREDUCE-479-2.patch, MAPREDUCE-479-3.patch, MAPREDUCE-479.patch Current clienttrace messages from shuffles note only the destination map ID but not the source reduce ID. Having both source and destination ID of each shuffle enables full tracing of execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-479) Add reduce ID to shuffle clienttrace
[ https://issues.apache.org/jira/browse/MAPREDUCE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12730928#action_12730928 ] Jiaqi Tan commented on MAPREDUCE-479: - Tests not required because the updates were made only to logging statements and do not affect core functionality. Manual verification was performed with a build and hand-inspection of HTTP query string of shuffle requests and clienttrace log messages generated by the TaskTracker. Add reduce ID to shuffle clienttrace Key: MAPREDUCE-479 URL: https://issues.apache.org/jira/browse/MAPREDUCE-479 Project: Hadoop Map/Reduce Issue Type: Improvement Affects Versions: 0.21.0 Reporter: Jiaqi Tan Assignee: Jiaqi Tan Priority: Minor Fix For: 0.21.0 Attachments: HADOOP-6013.patch, MAPREDUCE-479-1.patch, MAPREDUCE-479-2.patch, MAPREDUCE-479-3.patch, MAPREDUCE-479.patch Current clienttrace messages from shuffles note only the destination map ID but not the source reduce ID. Having both source and destination ID of each shuffle enables full tracing of execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
