[jira] [Updated] (MAPREDUCE-6578) Add support for HDFS heterogeneous storage testing to TestDFSIO
[ https://issues.apache.org/jira/browse/MAPREDUCE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated MAPREDUCE-6578: - Status: Patch Available (was: Open) > Add support for HDFS heterogeneous storage testing to TestDFSIO > --- > > Key: MAPREDUCE-6578 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6578 > Project: Hadoop Map/Reduce > Issue Type: New Feature >Reporter: Wei Zhou >Assignee: Wei Zhou > Attachments: MAPREDUCE-6578.00.patch, MAPREDUCE-6578.01.patch > > > HDFS heterogeneous storage allows user to store data blocks to different > storage medias according to predefined storage policies. Only 'Default' > policy is supported in current TestDFSIO implementation. This is going to add > an new option to enable tests of other storage polices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-6578) Add support for HDFS heterogeneous storage testing to TestDFSIO
[ https://issues.apache.org/jira/browse/MAPREDUCE-6578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated MAPREDUCE-6578: - Attachment: MAPREDUCE-6578.01.patch Rebased the patch. > Add support for HDFS heterogeneous storage testing to TestDFSIO > --- > > Key: MAPREDUCE-6578 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6578 > Project: Hadoop Map/Reduce > Issue Type: New Feature >Reporter: Wei Zhou >Assignee: Wei Zhou > Attachments: MAPREDUCE-6578.00.patch, MAPREDUCE-6578.01.patch > > > HDFS heterogeneous storage allows user to store data blocks to different > storage medias according to predefined storage policies. Only 'Default' > policy is supported in current TestDFSIO implementation. This is going to add > an new option to enable tests of other storage polices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6628) Potential memory leak in CryptoOutputStream
[
https://issues.apache.org/jira/browse/MAPREDUCE-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431890#comment-15431890
]
Hadoop QA commented on MAPREDUCE-6628:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 19s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 14s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
40s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 54s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
29s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 51s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
43s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
28s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 20s
{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 15s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m 46s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 29s
{color} | {color:red} root: The patch generated 32 new + 232 unchanged - 4
fixed = 264 total (was 236) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 51s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
56s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 46s
{color} | {color:green} hadoop-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 21s
{color} | {color:green}
hadoop-mapreduce-project_hadoop-mapreduce-client_hadoop-mapreduce-client-core
generated 0 new + 2496 unchanged - 12 fixed = 2496 total (was 2508) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} hadoop-mapreduce-client-jobclient in the patch passed.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m 10s
{color} | {color:green} hadoop-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 4s
{color} | {color:green} hadoop-mapreduce-client-core in the patch passed.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 117m 9s
{color} | {color:green} hadoop-mapreduce-client-jobclient in the patch passed.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 166m 32s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:9560f25 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12804278/MAPREDUCE-6628.006.patch
|
| JIRA Issue | MAPREDUCE-6628 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 86f931470f41 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (MAPREDUCE-5507) MapReduce reducer ramp down is suboptimal with potential job-hanging issues
[ https://issues.apache.org/jira/browse/MAPREDUCE-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431740#comment-15431740 ] Karthik Kambatla commented on MAPREDUCE-5507: - [~varun_saxena] - this appears to be very similar to issues fixed in MAPREDUCE-6513 and MAPREDUCE-6514. Can this be closed as a duplicate? > MapReduce reducer ramp down is suboptimal with potential job-hanging issues > --- > > Key: MAPREDUCE-5507 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5507 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: applicationmaster >Reporter: Omkar Vinit Joshi >Assignee: Omkar Vinit Joshi >Priority: Critical > Attachments: MAPREDUCE-5507.20130922.1.patch > > > Today if we are setting "yarn.app.mapreduce.am.job.reduce.rampup.limit" and > "mapreduce.job.reduce.slowstart.completedmaps" then reducers are launched > more aggressively. However the calculation to either Ramp up or Ramp down > reducer is not done in most optimal way. > * If MR AM at any point sees situation something like > ** scheduledMaps : 30 > ** scheduledReducers : 10 > ** assignedMaps : 0 > ** assignedReducers : 11 > ** finishedMaps : 120 > ** headroom : 756 ( when your map /reduce task needs only 512mb) > * then today it simply hangs because it thinks that there is sufficient room > to launch one more mapper and therefore there is no need to ramp down. > However, if this continues forever then this is not the correct way / optimal > way. > * Ideally for MR AM when it sees that assignedMaps drops have dropped to 0 > and there are running reducers around then it should wait for certain time ( > upper limited by average map task completion time ... for heuristic > sake)..but after that if still it doesn't get new container for map task then > it should preempt the reducer one by one with some interval and should ramp > up slowly... > ** Preemption of reducers can be done in little smarter way > *** preempt reducer on a node manager for which there is any pending map > request. > *** otherwise preempt any other reducer. MR AM will contribute to getting new > mapper by releasing such a reducer / container because it will reduce its > cluster consumption and thereby may become candidate for an allocation. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-6628) Potential memory leak in CryptoOutputStream
[
https://issues.apache.org/jira/browse/MAPREDUCE-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mariappan Asokan updated MAPREDUCE-6628:
Status: Patch Available (was: Open)
> Potential memory leak in CryptoOutputStream
> ---
>
> Key: MAPREDUCE-6628
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6628
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: security
>Affects Versions: 2.6.4
>Reporter: Mariappan Asokan
>Assignee: Mariappan Asokan
> Attachments: MAPREDUCE-6628.001.patch, MAPREDUCE-6628.002.patch,
> MAPREDUCE-6628.003.patch, MAPREDUCE-6628.004.patch, MAPREDUCE-6628.005.patch,
> MAPREDUCE-6628.006.patch
>
>
> There is a potential memory leak in {{CryptoOutputStream.java.}} It
> allocates two direct byte buffers ({{inBuffer}} and {{outBuffer}}) that get
> freed when {{close()}} method is called. Most of the time, {{close()}}
> method is called. However, when writing to intermediate Map output file or
> the spill files in {{MapTask}}, {{close()}} is never called since calling so
> would close the underlying stream which is not desirable. There is a single
> underlying physical stream that contains multiple logical streams one per
> partition of Map output.
> By default the amount of memory allocated per byte buffer is 128 KB and so
> the total memory allocated is 256 KB, This may not sound much. However, if
> the number of partitions (or number of reducers) is large (in the hundreds)
> and/or there are spill files created in {{MapTask}}, this can grow into a few
> hundred MB.
> I can think of two ways to address this issue:
> h2. Possible Fix - 1
> According to JDK documentation:
> {quote}
> The contents of direct buffers may reside outside of the normal
> garbage-collected heap, and so their impact upon the memory footprint of an
> application might not be obvious. It is therefore recommended that direct
> buffers be allocated primarily for large, long-lived buffers that are subject
> to the underlying system's native I/O operations. In general it is best to
> allocate direct buffers only when they yield a measureable gain in program
> performance.
> {quote}
> It is not clear to me whether there is any benefit of allocating direct byte
> buffers in {{CryptoOutputStream.java}}. In fact, there is a slight CPU
> overhead in moving data from {{outBuffer}} to a temporary byte array as per
> the following code in {{CryptoOutputStream.java}}.
> {code}
> /*
> * If underlying stream supports {@link ByteBuffer} write in future, needs
> * refine here.
> */
> final byte[] tmp = getTmpBuf();
> outBuffer.get(tmp, 0, len);
> out.write(tmp, 0, len);
> {code}
> Even if the underlying stream supports direct byte buffer IO (or direct IO in
> OS parlance), it is not clear whether it will yield any measurable
> performance gain.
> The fix would be to allocate a ByteBuffer on the heap for inBuffer and wrap a
> byte array in a {{ByteBuffer}} for {{outBuffer}}. By the way, the
> {{inBuffer}} and {{outBuffer}} have to be {{ByteBuffer}} as demanded by the
> {{encrypt()}} method in {{Encryptor}}.
> h2. Possible Fix - 2
> Assuming that we want to keep the buffers as direct byte buffers, we can
> create a new constructor to {{CryptoOutputStream}} and pass a boolean flag
> {{ownOutputStream}} to indicate whether the underlying stream will be owned
> by {{CryptoOutputStream}}. If it is true, then calling the {{close()}} method
> will close the underlying stream. Otherwise, when {{close()}} is called only
> the direct byte buffers will be freed and the underlying stream will not be
> closed.
> The scope of changes for this fix will be somewhat wider. We need to modify
> {{MapTask.java}}, {{CryptoUtils.java}}, and {{CryptoFSDataOutputStream.java}}
> as well to pass the ownership flag mentioned above.
> I can post a patch for either of the above. I welcome any other ideas from
> developers to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-6628) Potential memory leak in CryptoOutputStream
[
https://issues.apache.org/jira/browse/MAPREDUCE-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mariappan Asokan updated MAPREDUCE-6628:
Status: Open (was: Patch Available)
> Potential memory leak in CryptoOutputStream
> ---
>
> Key: MAPREDUCE-6628
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6628
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: security
>Affects Versions: 2.6.4
>Reporter: Mariappan Asokan
>Assignee: Mariappan Asokan
> Attachments: MAPREDUCE-6628.001.patch, MAPREDUCE-6628.002.patch,
> MAPREDUCE-6628.003.patch, MAPREDUCE-6628.004.patch, MAPREDUCE-6628.005.patch,
> MAPREDUCE-6628.006.patch
>
>
> There is a potential memory leak in {{CryptoOutputStream.java.}} It
> allocates two direct byte buffers ({{inBuffer}} and {{outBuffer}}) that get
> freed when {{close()}} method is called. Most of the time, {{close()}}
> method is called. However, when writing to intermediate Map output file or
> the spill files in {{MapTask}}, {{close()}} is never called since calling so
> would close the underlying stream which is not desirable. There is a single
> underlying physical stream that contains multiple logical streams one per
> partition of Map output.
> By default the amount of memory allocated per byte buffer is 128 KB and so
> the total memory allocated is 256 KB, This may not sound much. However, if
> the number of partitions (or number of reducers) is large (in the hundreds)
> and/or there are spill files created in {{MapTask}}, this can grow into a few
> hundred MB.
> I can think of two ways to address this issue:
> h2. Possible Fix - 1
> According to JDK documentation:
> {quote}
> The contents of direct buffers may reside outside of the normal
> garbage-collected heap, and so their impact upon the memory footprint of an
> application might not be obvious. It is therefore recommended that direct
> buffers be allocated primarily for large, long-lived buffers that are subject
> to the underlying system's native I/O operations. In general it is best to
> allocate direct buffers only when they yield a measureable gain in program
> performance.
> {quote}
> It is not clear to me whether there is any benefit of allocating direct byte
> buffers in {{CryptoOutputStream.java}}. In fact, there is a slight CPU
> overhead in moving data from {{outBuffer}} to a temporary byte array as per
> the following code in {{CryptoOutputStream.java}}.
> {code}
> /*
> * If underlying stream supports {@link ByteBuffer} write in future, needs
> * refine here.
> */
> final byte[] tmp = getTmpBuf();
> outBuffer.get(tmp, 0, len);
> out.write(tmp, 0, len);
> {code}
> Even if the underlying stream supports direct byte buffer IO (or direct IO in
> OS parlance), it is not clear whether it will yield any measurable
> performance gain.
> The fix would be to allocate a ByteBuffer on the heap for inBuffer and wrap a
> byte array in a {{ByteBuffer}} for {{outBuffer}}. By the way, the
> {{inBuffer}} and {{outBuffer}} have to be {{ByteBuffer}} as demanded by the
> {{encrypt()}} method in {{Encryptor}}.
> h2. Possible Fix - 2
> Assuming that we want to keep the buffers as direct byte buffers, we can
> create a new constructor to {{CryptoOutputStream}} and pass a boolean flag
> {{ownOutputStream}} to indicate whether the underlying stream will be owned
> by {{CryptoOutputStream}}. If it is true, then calling the {{close()}} method
> will close the underlying stream. Otherwise, when {{close()}} is called only
> the direct byte buffers will be freed and the underlying stream will not be
> closed.
> The scope of changes for this fix will be somewhat wider. We need to modify
> {{MapTask.java}}, {{CryptoUtils.java}}, and {{CryptoFSDataOutputStream.java}}
> as well to pass the ownership flag mentioned above.
> I can post a patch for either of the above. I welcome any other ideas from
> developers to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6761) Regression when handling providers - invalid configuration ServiceConfiguration causes Cluster initialization failure
[
https://issues.apache.org/jira/browse/MAPREDUCE-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431681#comment-15431681
]
Hadoop QA commented on MAPREDUCE-6761:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 21s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
38s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 23s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 28s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
45s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 21s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 22s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 22s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 25s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 5s
{color} | {color:green} hadoop-mapreduce-client-core in the patch passed.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 15m 8s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:9560f25 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12824927/MAPREDUCE-6761.5.patch
|
| JIRA Issue | MAPREDUCE-6761 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 98da27d4c254 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh
|
| git revision | trunk / 22fc46d |
| Default Java | 1.8.0_101 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/6686/testReport/ |
| modules | C:
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core
U:
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core |
| Console output |
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/6686/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Regression when handling providers - invalid configuration
> ServiceConfiguration causes Cluster initialization failure
> -
>
> Key: MAPREDUCE-6761
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6761
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv2
>Affects Versions: 3.0.0-alpha2
>Reporter:
[jira] [Updated] (MAPREDUCE-6761) Regression when handling providers - invalid configuration ServiceConfiguration causes Cluster initialization failure
[ https://issues.apache.org/jira/browse/MAPREDUCE-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Vary updated MAPREDUCE-6761: -- Attachment: MAPREDUCE-6761.5.patch Thanks [~jlowe] for the comment. I decided not to check the selected protocolprovider class explicitly, since the goal of the test is to validate the exception handling, and not to validate the protocolprovider selection logic itself. To validate the selected provider class itself (when we have multiple possible providers) would be a different testcase altogether. With that in mind, I changed the type check to a null check, so it would be easier to read the code, and it expresses better the decision I have made above. Thanks, Peter > Regression when handling providers - invalid configuration > ServiceConfiguration causes Cluster initialization failure > - > > Key: MAPREDUCE-6761 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6761 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: mrv2 >Affects Versions: 3.0.0-alpha2 >Reporter: Peter Vary >Assignee: Peter Vary > Labels: supportability > Attachments: MAPREDUCE-6761.2.patch, MAPREDUCE-6761.3.patch, > MAPREDUCE-6761.4.patch, MAPREDUCE-6761.5.patch, MAPREDUCE-6761.patch > > > When a rogue org.apache.hadoop.mapreduce.protocol.ClientProtocolProvider > defines a provider that is not on classpath, then the initialization is > failed with the following exception: > java.util.ServiceConfigurationError: > org.apache.hadoop.mapreduce.protocol.ClientProtocolProvider: Provider > org.apache.hadoop.mapred.YarnClientProtocolProvider not found > at java.util.ServiceLoader.fail(ServiceLoader.java:239) > at java.util.ServiceLoader.access$300(ServiceLoader.java:185) > at > java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:372) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > at org.apache.hadoop.mapreduce.Cluster.initProviderList(Cluster.java:84) > at org.apache.hadoop.mapreduce.Cluster.initialize(Cluster.java:114) > at org.apache.hadoop.mapreduce.Cluster.(Cluster.java:108) > at org.apache.hadoop.mapreduce.Cluster.(Cluster.java:101) > at org.apache.hadoop.mapred.JobClient.init(JobClient.java:477) > at org.apache.hadoop.mapred.JobClient.(JobClient.java:455) > This regression is caused by MAPREDUCE-6473 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6764) Teragen LOG initialization bug
[ https://issues.apache.org/jira/browse/MAPREDUCE-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431586#comment-15431586 ] Yufei Gu commented on MAPREDUCE-6764: - Hi [~Naganarasimha], thanks a lot for the review. The jenkins run looks good and there is no need to add the additional test case for this change. > Teragen LOG initialization bug > -- > > Key: MAPREDUCE-6764 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6764 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: examples >Reporter: Yufei Gu >Assignee: Yufei Gu >Priority: Minor > Attachments: MAPREDUCE-6764.001.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-5817) Mappers get rescheduled on node transition even after all reducers are completed
[ https://issues.apache.org/jira/browse/MAPREDUCE-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431581#comment-15431581 ] Chris Trezzo commented on MAPREDUCE-5817: - Adding 2.6.5 to the target versions with the intention of backporting this to branch-2.6. Please let me know if you think otherwise. Thanks! > Mappers get rescheduled on node transition even after all reducers are > completed > > > Key: MAPREDUCE-5817 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5817 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: applicationmaster >Affects Versions: 2.3.0 >Reporter: Sangjin Lee >Assignee: Sangjin Lee > Fix For: 2.7.3 > > Attachments: MAPREDUCE-5817.001.patch, MAPREDUCE-5817.002.patch, > mapreduce-5817.patch > > > We're seeing a behavior where a job runs long after all reducers were already > finished. We found that the job was rescheduling and running a number of > mappers beyond the point of reducer completion. In one situation, the job ran > for some 9 more hours after all reducers completed! > This happens because whenever a node transition (to an unusable state) comes > into the app master, it just reschedules all mappers that already ran on the > node in all cases. > Therefore, if any node transition has a potential to extend the job period. > Once this window opens, another node transition can prolong it, and this can > happen indefinitely in theory. > If there is some instability in the pool (unhealthy, etc.) for a duration, > then any big job is severely vulnerable to this problem. > If all reducers have been completed, JobImpl.actOnUnusableNode() should not > reschedule mapper tasks. If all reducers are completed, the mapper outputs > are no longer needed, and there is no need to reschedule mapper tasks as they > would not be consumed anyway. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-5817) Mappers get rescheduled on node transition even after all reducers are completed
[ https://issues.apache.org/jira/browse/MAPREDUCE-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Trezzo updated MAPREDUCE-5817: Target Version/s: 2.8.0, 2.6.5 (was: 2.8.0) > Mappers get rescheduled on node transition even after all reducers are > completed > > > Key: MAPREDUCE-5817 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5817 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: applicationmaster >Affects Versions: 2.3.0 >Reporter: Sangjin Lee >Assignee: Sangjin Lee > Fix For: 2.7.3 > > Attachments: MAPREDUCE-5817.001.patch, MAPREDUCE-5817.002.patch, > mapreduce-5817.patch > > > We're seeing a behavior where a job runs long after all reducers were already > finished. We found that the job was rescheduling and running a number of > mappers beyond the point of reducer completion. In one situation, the job ran > for some 9 more hours after all reducers completed! > This happens because whenever a node transition (to an unusable state) comes > into the app master, it just reschedules all mappers that already ran on the > node in all cases. > Therefore, if any node transition has a potential to extend the job period. > Once this window opens, another node transition can prolong it, and this can > happen indefinitely in theory. > If there is some instability in the pool (unhealthy, etc.) for a duration, > then any big job is severely vulnerable to this problem. > If all reducers have been completed, JobImpl.actOnUnusableNode() should not > reschedule mapper tasks. If all reducers are completed, the mapper outputs > are no longer needed, and there is no need to reschedule mapper tasks as they > would not be consumed anyway. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-6315) Implement retrieval of logs for crashed MR-AM via jhist in the staging directory
[ https://issues.apache.org/jira/browse/MAPREDUCE-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kumar Vavilapalli updated MAPREDUCE-6315: --- Status: Open (was: Patch Available) > Implement retrieval of logs for crashed MR-AM via jhist in the staging > directory > > > Key: MAPREDUCE-6315 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6315 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: client, mr-am >Affects Versions: 2.7.0 >Reporter: Gera Shegalov >Priority: Critical > Labels: BB2015-05-TBR > Attachments: MAPREDUCE-6315.001.patch, MAPREDUCE-6315.002.patch, > MAPREDUCE-6315.003.patch > > > When all AM attempts crash, there is no record of them in JHS. Thus no easy > way to get the logs. This JIRA automates the procedure by utilizing the jhist > file in the staging directory. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-6315) Implement retrieval of logs for crashed MR-AM via jhist in the staging directory
[
https://issues.apache.org/jira/browse/MAPREDUCE-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinod Kumar Vavilapalli updated MAPREDUCE-6315:
---
Target Version/s: 2.9.0 (was: 2.8.0)
I applied the patch and looked at it. {{mapred job -logs}} is an arcane command
that I don't know of a lot of users using. It definitely isn't the first place
our users go - that would be the web UI. Given that, I also agree that putting
this in the JobHistory-UI is a minimum requirement.
Even without that, this patch needs more work as commented above.
Note that YARN's the ResourceManager does have these log-links against each
app-attempt.
Given all of the above, I am moving this into 2.9 and unblocking 2.8.0. Please
revert back if you disagree. Tx.
> Implement retrieval of logs for crashed MR-AM via jhist in the staging
> directory
>
>
> Key: MAPREDUCE-6315
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6315
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: client, mr-am
>Affects Versions: 2.7.0
>Reporter: Gera Shegalov
>Priority: Critical
> Labels: BB2015-05-TBR
> Attachments: MAPREDUCE-6315.001.patch, MAPREDUCE-6315.002.patch,
> MAPREDUCE-6315.003.patch
>
>
> When all AM attempts crash, there is no record of them in JHS. Thus no easy
> way to get the logs. This JIRA automates the procedure by utilizing the jhist
> file in the staging directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6761) Regression when handling providers - invalid configuration ServiceConfiguration causes Cluster initialization failure
[
https://issues.apache.org/jira/browse/MAPREDUCE-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431352#comment-15431352
]
Jason Lowe commented on MAPREDUCE-6761:
---
Thanks for updating the patch. Looks good overall with a minor nit in the test:
{code}
// Check that we get the acceptable client, even after
// failure in instantiation.
assertThat("Unexpected type of clientProtocolProvider",
testCluster.getClient(),
instanceOf(ClientProtocol.class));
{code}
The ServiceLoader is only going to load classes that can be cast to a
ClientProtocol, so if the Cluster constructor doesn't fail then this too will
never fail. In addition ClientProtocol is the return type for the
Cluster#getClient method, so this is essentially a complicated null check since
that's the only return value that could cause the test to fail. It also isn't
testing which client protocol type we received, since the mock always returns
the same type when it isn't throwing an error. The test would be more robust
if the mock could return different derived classes from ClientProtocol and
verify we received the correct one.
Fairly minor nit though, so I'm still +1 on the current patch if that isn't
addressed.
> Regression when handling providers - invalid configuration
> ServiceConfiguration causes Cluster initialization failure
> -
>
> Key: MAPREDUCE-6761
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6761
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv2
>Affects Versions: 3.0.0-alpha2
>Reporter: Peter Vary
>Assignee: Peter Vary
> Labels: supportability
> Attachments: MAPREDUCE-6761.2.patch, MAPREDUCE-6761.3.patch,
> MAPREDUCE-6761.4.patch, MAPREDUCE-6761.patch
>
>
> When a rogue org.apache.hadoop.mapreduce.protocol.ClientProtocolProvider
> defines a provider that is not on classpath, then the initialization is
> failed with the following exception:
> java.util.ServiceConfigurationError:
> org.apache.hadoop.mapreduce.protocol.ClientProtocolProvider: Provider
> org.apache.hadoop.mapred.YarnClientProtocolProvider not found
> at java.util.ServiceLoader.fail(ServiceLoader.java:239)
> at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:372)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at org.apache.hadoop.mapreduce.Cluster.initProviderList(Cluster.java:84)
> at org.apache.hadoop.mapreduce.Cluster.initialize(Cluster.java:114)
> at org.apache.hadoop.mapreduce.Cluster.(Cluster.java:108)
> at org.apache.hadoop.mapreduce.Cluster.(Cluster.java:101)
> at org.apache.hadoop.mapred.JobClient.init(JobClient.java:477)
> at org.apache.hadoop.mapred.JobClient.(JobClient.java:455)
> This regression is caused by MAPREDUCE-6473
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6761) Regression when handling providers - invalid configuration ServiceConfiguration causes Cluster initialization failure
[ https://issues.apache.org/jira/browse/MAPREDUCE-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431252#comment-15431252 ] Ray Chiang commented on MAPREDUCE-6761: --- Thanks for the cleanup [~kshukla] and [~pvary]. The current patch looks good to me. +1 Does anyone else have any follow up comments? > Regression when handling providers - invalid configuration > ServiceConfiguration causes Cluster initialization failure > - > > Key: MAPREDUCE-6761 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6761 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: mrv2 >Affects Versions: 3.0.0-alpha2 >Reporter: Peter Vary >Assignee: Peter Vary > Labels: supportability > Attachments: MAPREDUCE-6761.2.patch, MAPREDUCE-6761.3.patch, > MAPREDUCE-6761.4.patch, MAPREDUCE-6761.patch > > > When a rogue org.apache.hadoop.mapreduce.protocol.ClientProtocolProvider > defines a provider that is not on classpath, then the initialization is > failed with the following exception: > java.util.ServiceConfigurationError: > org.apache.hadoop.mapreduce.protocol.ClientProtocolProvider: Provider > org.apache.hadoop.mapred.YarnClientProtocolProvider not found > at java.util.ServiceLoader.fail(ServiceLoader.java:239) > at java.util.ServiceLoader.access$300(ServiceLoader.java:185) > at > java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:372) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > at org.apache.hadoop.mapreduce.Cluster.initProviderList(Cluster.java:84) > at org.apache.hadoop.mapreduce.Cluster.initialize(Cluster.java:114) > at org.apache.hadoop.mapreduce.Cluster.(Cluster.java:108) > at org.apache.hadoop.mapreduce.Cluster.(Cluster.java:101) > at org.apache.hadoop.mapred.JobClient.init(JobClient.java:477) > at org.apache.hadoop.mapred.JobClient.(JobClient.java:455) > This regression is caused by MAPREDUCE-6473 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-6750) TestHSAdminServer.testRefreshSuperUserGroups is failing
[
https://issues.apache.org/jira/browse/MAPREDUCE-6750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kihwal Lee updated MAPREDUCE-6750:
--
Fix Version/s: (was: 2.9.0)
2.8.0
> TestHSAdminServer.testRefreshSuperUserGroups is failing
> ---
>
> Key: MAPREDUCE-6750
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6750
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: test
>Reporter: Kihwal Lee
>Assignee: Kihwal Lee
>Priority: Minor
> Fix For: 2.8.0
>
> Attachments: MAPREDUCE-6750.patch
>
>
> HADOOP-13442 changed {{AccessControlList}} to call {{getGroups()}} instead of
> {{getGroupNames()}}. It should work if the mocks are updated to stub the
> right method and return the right type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6764) Teragen LOG initialization bug
[
https://issues.apache.org/jira/browse/MAPREDUCE-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15430136#comment-15430136
]
Hadoop QA commented on MAPREDUCE-6764:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 21s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} 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. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
44s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 17s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 23s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
28s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 15s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 19s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
33s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 30s
{color} | {color:green} hadoop-mapreduce-examples in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 12m 13s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:9560f25 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12824777/MAPREDUCE-6764.001.patch
|
| JIRA Issue | MAPREDUCE-6764 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 7f7ba4f52e29 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh
|
| git revision | trunk / 115ecb5 |
| Default Java | 1.8.0_101 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/6685/testReport/ |
| modules | C: hadoop-mapreduce-project/hadoop-mapreduce-examples U:
hadoop-mapreduce-project/hadoop-mapreduce-examples |
| Console output |
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/6685/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Teragen LOG initialization bug
> --
>
> Key: MAPREDUCE-6764
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6764
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: examples
>Reporter: Yufei Gu
>Assignee: Yufei Gu
>Priority: Minor
> Attachments: MAPREDUCE-6764.001.patch
>
>
--
This
[jira] [Commented] (MAPREDUCE-6764) Teragen LOG initialization bug
[ https://issues.apache.org/jira/browse/MAPREDUCE-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15430114#comment-15430114 ] Naganarasimha G R commented on MAPREDUCE-6764: -- Simple fix can be committed on jenkins run ! > Teragen LOG initialization bug > -- > > Key: MAPREDUCE-6764 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6764 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: examples >Reporter: Yufei Gu >Assignee: Yufei Gu >Priority: Minor > Attachments: MAPREDUCE-6764.001.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-6764) Teragen LOG initialization bug
[ https://issues.apache.org/jira/browse/MAPREDUCE-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yufei Gu updated MAPREDUCE-6764: Status: Patch Available (was: Open) > Teragen LOG initialization bug > -- > > Key: MAPREDUCE-6764 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6764 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: examples >Reporter: Yufei Gu >Assignee: Yufei Gu >Priority: Minor > Attachments: MAPREDUCE-6764.001.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Updated] (MAPREDUCE-6764) Teragen LOG initialization bug
[ https://issues.apache.org/jira/browse/MAPREDUCE-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yufei Gu updated MAPREDUCE-6764: Attachment: MAPREDUCE-6764.001.patch > Teragen LOG initialization bug > -- > > Key: MAPREDUCE-6764 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6764 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: examples >Reporter: Yufei Gu >Assignee: Yufei Gu >Priority: Minor > Attachments: MAPREDUCE-6764.001.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Created] (MAPREDUCE-6764) Teragen LOG initialization bug
Yufei Gu created MAPREDUCE-6764: --- Summary: Teragen LOG initialization bug Key: MAPREDUCE-6764 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6764 Project: Hadoop Map/Reduce Issue Type: Bug Components: examples Reporter: Yufei Gu Assignee: Yufei Gu Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
