[jira] [Commented] (MAPREDUCE-6424) Store MR counters as timeline metrics instead of event
[ https://issues.apache.org/jira/browse/MAPREDUCE-6424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261515#comment-15261515 ] Naganarasimha G R commented on MAPREDUCE-6424: -- bq. If we don't do this, then we need to find a way to transfer metrics from certain framework-specific entities to the application entities so that they can be aggregated. I would think that would be considerably more involved. Agree, i was thinking of linking this jira to YARN-3401 and comment there to provide alternate approach to publish app metrics (& configuration as part of YARN-3401) from app and currrently applications are publishing System entities directlty. bq. As you mentioned, we can carry on the discussion in a new JIRA. Ok Have uploaded the patch with fixes for you suggestion [~sjlee0]. > Store MR counters as timeline metrics instead of event > -- > > Key: MAPREDUCE-6424 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6424 > Project: Hadoop Map/Reduce > Issue Type: Sub-task >Reporter: Junping Du >Assignee: Naganarasimha G R > Labels: yarn-2928-1st-milestone > Attachments: MAPREDUCE-6424-YARN-2928.v1.001.patch, > MAPREDUCE-6424-YARN-2928.v1.002.patch > > > In MAPREDUCE-6327, we make map/reduce counters get encoded from > JobFinishedEvent as timeline events with counters details in JSON format. > We need to store framework specific counters as metrics in timeline service > to support query, aggregation, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MAPREDUCE-6424) Store MR counters as timeline metrics instead of event
[ https://issues.apache.org/jira/browse/MAPREDUCE-6424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Naganarasimha G R updated MAPREDUCE-6424: - Attachment: MAPREDUCE-6424-YARN-2928.v1.002.patch > Store MR counters as timeline metrics instead of event > -- > > Key: MAPREDUCE-6424 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6424 > Project: Hadoop Map/Reduce > Issue Type: Sub-task >Reporter: Junping Du >Assignee: Naganarasimha G R > Labels: yarn-2928-1st-milestone > Attachments: MAPREDUCE-6424-YARN-2928.v1.001.patch, > MAPREDUCE-6424-YARN-2928.v1.002.patch > > > In MAPREDUCE-6327, we make map/reduce counters get encoded from > JobFinishedEvent as timeline events with counters details in JSON format. > We need to store framework specific counters as metrics in timeline service > to support query, aggregation, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MAPREDUCE-6652) Add configuration property to prevent JHS from loading jobs with a task count greater than X
[
https://issues.apache.org/jira/browse/MAPREDUCE-6652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261133#comment-15261133
]
Ray Chiang commented on MAPREDUCE-6652:
---
Looks pretty good to me. A few minor nits/suggestions:
* Rename oversized() to isOversized()
* In the return value for oversized(), please add parentheses
* In HsJobBlock#render(), some cleanup and add one other actionable item for
supportability:
{noformat}
html.p()._("The job has a total of " + taskCount + " tasks. ")
._("Any job larger than " + oversizedJob.getMaxTasksAllowed() +
" will not be loaded.")._();
html.p()._("You can either use the command line tool: 'mapred job -history'"
+ " to view large jobs or adjust the property " +
JHAdminConfig.MR_HS_LOADED_JOBS_TASKS_MAX + ".")._();
{noformat}
> Add configuration property to prevent JHS from loading jobs with a task count
> greater than X
>
>
> Key: MAPREDUCE-6652
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6652
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: jobhistoryserver
>Reporter: Haibo Chen
>Assignee: Haibo Chen
> Attachments: mapreduce6652.001.patch, mapreduce6652.002.patch
>
>
> Jobs with large number of tasks can have job history files that are large in
> size and resource-consuming(mainly memory) to parse in Job History Server. If
> there are many such jobs, the job history server can very easily hang.
> It would be a good usability feature if we added a new config property that
> could be set to X, where the JHS wouldn't load the details for a job with
> more than X tasks. The job would still show up on the list of jobs page, but
> clicking on it would give a warning message that the job is too big, instead
> of actually loading the job. This way we can prevent users from loading a job
> that's way too big for the JHS, which currently makes the JHS hang. The
> default value can be -1 so that it's disabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MAPREDUCE-6684) High contention on scanning of user directory under immediate_done in Job History Server
[
https://issues.apache.org/jira/browse/MAPREDUCE-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260817#comment-15260817
]
Karthik Kambatla commented on MAPREDUCE-6684:
-
bq. If ATSv2 is going to completely replace the JHS
While the need for writing out and copying/parsing jhist files might be
replaced by accesses to ATS, I would think the JHS itself would stick around to
provide MR-specific UI it does today. Not sure if ATS would be able to expose
the right abstractions for each framework to plugin the appropriate UI.
bq. Because it is complex with lots of race conditions to work through I worry
we can introduce new subtle bugs when it's rewritten.
bq. But I think a lot of the races are inherent in the problem, some users are
trying to read data and get a consistent view of it while at the same time the
data is moving from one place to another.
Agree with you both. Given it is mostly stable barring the occasional
inefficiency, we should probably just leave it alone. If we run into more
issues around this, may be we could revisit cleaning it up.
In terms of potential cleanups:
# When fetching information regarding one job, we scan the entire intermediate
directory potentially triggering other moves. Instead, it would be nice if it
looks only for that specific job. And, if that very file is being moved, wait
for the move to complete. That way, we don't have to think about a read thread
accessing files corresponding to other jobs.
# HistoryFileManager is rather long - moving out some of the inner classes
might make for cleaner abstractions and more explicit locking where needed for
readability.
# I keep thinking about doing the move in a separate class/thread and some way
for the read threads to communicate with this move thread, but that might just
result in more complicated code. I will have to poke around to figure out which
way is simpler; don't think I can get it to anytime soon though.
> High contention on scanning of user directory under immediate_done in Job
> History Server
>
>
> Key: MAPREDUCE-6684
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6684
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: jobhistoryserver
>Affects Versions: 2.7.0
>Reporter: Haibo Chen
>Assignee: Haibo Chen
>Priority: Critical
> Attachments: jhs-jstacks-service-monitor-running.tar.gz,
> jhs-jstacks-service-monitor-stopped.tar.gz
>
>
> HistoryFileManager.scanIntermediateDirectory() in JHS acquires a lock on each
> user directory it tries to scan (move or delete files under the user
> directory as necessary). This method is called in a thread in JobHistory that
> performs periodical scanning of intermediate directory, and can also be
> called by web server threads for each Web API call made by a JHS client. In
> cases where there are many concurrent Web API calls/connections to JHS, all
> but one thread are blocked on the lock on the user directory. Eventually,
> client connects will time out, but the threads in JHS will not be killed and
> leave a lot of TCP connections in CLOSE_WAIT state.
> {noformat}
> [systest@vb1120 ~]$ sudo netstat -nap | grep 63729 | sort -k 4
> tcp0 0 10.17.202.19:10020 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:10020 10.17.198.30:33010
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.200.30:33980
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.202.10:59625
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.202.13:35765
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10033 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:19888 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:19888 10.17.198.30:35103
> ESTABLISHED 63729/java
> tcp 277 0 10.17.202.19:19888 10.17.198.30:43670
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:19888 10.17.198.30:45453
> ESTABLISHED 63729/java
> tcp 277 0 10.17.202.19:19888 10.17.198.30:49184
> ESTABLISHED 63729/java
> tcp1 0 10.17.202.19:19888 10.17.202.13:49992
> CLOSE_WAIT 63729/java
> tcp 261 0 10.17.202.19:19888 10.17.202.13:52703
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52707
[jira] [Commented] (MAPREDUCE-4285) Code sample in Tool javadocs is broken
[
https://issues.apache.org/jira/browse/MAPREDUCE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260239#comment-15260239
]
Hadoop QA commented on MAPREDUCE-4285:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s
{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} 9m
10s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 0s
{color} | {color:green} trunk passed with JDK v1.8.0_92 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 20s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 59s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
36s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 0s
{color} | {color:green} trunk passed with JDK v1.8.0_92 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 10s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 22s
{color} | {color:green} the patch passed with JDK v1.8.0_92 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 22s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 27s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m 27s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 58s
{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} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed with JDK v1.8.0_92 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m 5s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.8.0_92.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m 48s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 74m 39s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:fbe3e86 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12801015/MAPREDUCE-4285.001.patch
|
| JIRA Issue | MAPREDUCE-4285 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 1f45954be186 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-5306) HistoryFileManager.mkdir() doesn't handle case where dest path exists -and is a file
[
https://issues.apache.org/jira/browse/MAPREDUCE-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260172#comment-15260172
]
Hadoop QA commented on MAPREDUCE-5306:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 9s
{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
41s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 15s
{color} | {color:green} trunk passed with JDK v1.8.0_92 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 17s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 22s
{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
31s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 12s
{color} | {color:green} trunk passed with JDK v1.8.0_92 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 13s
{color} | {color:green} the patch passed with JDK v1.8.0_92 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 13s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 15s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 15s
{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
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
39s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 10s
{color} | {color:green} the patch passed with JDK v1.8.0_92 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 13s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 26s {color}
| {color:red} hadoop-mapreduce-client-hs in the patch failed with JDK
v1.8.0_92. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 2m 51s {color}
| {color:red} hadoop-mapreduce-client-hs in the patch failed with JDK
v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 18m 6s {color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_92 Failed junit tests |
hadoop.mapreduce.v2.hs.TestJobHistoryServer |
| | hadoop.mapreduce.v2.hs.TestHistoryFileManager |
| | hadoop.mapreduce.v2.hs.TestJobHistoryParsing |
| | hadoop.mapreduce.v2.hs.TestJobHistoryEvents |
| | hadoop.mapreduce.v2.hs.TestJobHistory |
| JDK v1.7.0_95 Failed junit tests |
hadoop.mapreduce.v2.hs.TestJobHistoryServer |
| | hadoop.mapreduce.v2.hs.TestHistoryFileManager |
| | hadoop.mapreduce.v2.hs.TestJobHistoryParsing |
| |
[jira] [Commented] (MAPREDUCE-6684) High contention on scanning of user directory under immediate_done in Job History Server
[
https://issues.apache.org/jira/browse/MAPREDUCE-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260149#comment-15260149
]
Robert Joseph Evans commented on MAPREDUCE-6684:
I agree with Jason. The code is complex and there are a lot of races in there.
Making the code simpler and still solving the problem would be great. But I
think a lot of the races are inherent in the problem, some users are trying to
read data and get a consistent view of it while at the same time the data is
moving from one place to another. In many cases making something have less
lock contention inherently makes the code more complex. Although I am happy to
be proven wrong so if you have some specific suggestions on what and how to
clean it up that would be helpful in understanding if it is worth the risk.
> High contention on scanning of user directory under immediate_done in Job
> History Server
>
>
> Key: MAPREDUCE-6684
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6684
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: jobhistoryserver
>Affects Versions: 2.7.0
>Reporter: Haibo Chen
>Assignee: Haibo Chen
>Priority: Critical
> Attachments: jhs-jstacks-service-monitor-running.tar.gz,
> jhs-jstacks-service-monitor-stopped.tar.gz
>
>
> HistoryFileManager.scanIntermediateDirectory() in JHS acquires a lock on each
> user directory it tries to scan (move or delete files under the user
> directory as necessary). This method is called in a thread in JobHistory that
> performs periodical scanning of intermediate directory, and can also be
> called by web server threads for each Web API call made by a JHS client. In
> cases where there are many concurrent Web API calls/connections to JHS, all
> but one thread are blocked on the lock on the user directory. Eventually,
> client connects will time out, but the threads in JHS will not be killed and
> leave a lot of TCP connections in CLOSE_WAIT state.
> {noformat}
> [systest@vb1120 ~]$ sudo netstat -nap | grep 63729 | sort -k 4
> tcp0 0 10.17.202.19:10020 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:10020 10.17.198.30:33010
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.200.30:33980
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.202.10:59625
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.202.13:35765
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10033 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:19888 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:19888 10.17.198.30:35103
> ESTABLISHED 63729/java
> tcp 277 0 10.17.202.19:19888 10.17.198.30:43670
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:19888 10.17.198.30:45453
> ESTABLISHED 63729/java
> tcp 277 0 10.17.202.19:19888 10.17.198.30:49184
> ESTABLISHED 63729/java
> tcp1 0 10.17.202.19:19888 10.17.202.13:49992
> CLOSE_WAIT 63729/java
> tcp 261 0 10.17.202.19:19888 10.17.202.13:52703
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52707
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52708
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52710
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52714
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52723
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52726
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52727
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52739
> CLOSE_WAIT 63729/java
> tcp 261 0 10.17.202.19:19888 10.17.202.13:52749
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52753
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52757
[jira] [Updated] (MAPREDUCE-5306) HistoryFileManager.mkdir() doesn't handle case where dest path exists -and is a file
[
https://issues.apache.org/jira/browse/MAPREDUCE-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gergely Novák updated MAPREDUCE-5306:
-
Attachment: MAPREDUCE-5306.001.patch
> HistoryFileManager.mkdir() doesn't handle case where dest path exists -and is
> a file
>
>
> Key: MAPREDUCE-5306
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5306
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Reporter: Steve Loughran
>Priority: Minor
> Attachments: MAPREDUCE-5306.001.patch
>
>
> The {{HistoryFileManager.mkdir()}} code handles the path existing simply by
> logging that the dir exists, and returning for everything else to work.
> There's a big assumption there: that the path resolves to a directory. A
> check needs to be made that this assumption is valid -throwing some IOE
> subclass if it's just a file
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MAPREDUCE-5306) HistoryFileManager.mkdir() doesn't handle case where dest path exists -and is a file
[
https://issues.apache.org/jira/browse/MAPREDUCE-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gergely Novák updated MAPREDUCE-5306:
-
Status: Patch Available (was: Open)
> HistoryFileManager.mkdir() doesn't handle case where dest path exists -and is
> a file
>
>
> Key: MAPREDUCE-5306
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5306
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Reporter: Steve Loughran
>Priority: Minor
> Attachments: MAPREDUCE-5306.001.patch
>
>
> The {{HistoryFileManager.mkdir()}} code handles the path existing simply by
> logging that the dir exists, and returning for everything else to work.
> There's a big assumption there: that the path resolves to a directory. A
> check needs to be made that this assumption is valid -throwing some IOE
> subclass if it's just a file
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MAPREDUCE-6684) High contention on scanning of user directory under immediate_done in Job History Server
[
https://issues.apache.org/jira/browse/MAPREDUCE-6684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260092#comment-15260092
]
Jason Lowe commented on MAPREDUCE-6684:
---
Yes, the move logic is not ideal, and it would be nice if it were cleaner.
Because it is complex with lots of race conditions to work through I worry we
can introduce new subtle bugs when it's rewritten. If ATSv2 is going to
completely replace the JHS in a reasonable timeframe then I'm thinking it's
probably not worth the rewrite. However if the JHS is going to live for quite
a while longer then it could be a worthwhile effort if done carefully.
> High contention on scanning of user directory under immediate_done in Job
> History Server
>
>
> Key: MAPREDUCE-6684
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6684
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: jobhistoryserver
>Affects Versions: 2.7.0
>Reporter: Haibo Chen
>Assignee: Haibo Chen
>Priority: Critical
> Attachments: jhs-jstacks-service-monitor-running.tar.gz,
> jhs-jstacks-service-monitor-stopped.tar.gz
>
>
> HistoryFileManager.scanIntermediateDirectory() in JHS acquires a lock on each
> user directory it tries to scan (move or delete files under the user
> directory as necessary). This method is called in a thread in JobHistory that
> performs periodical scanning of intermediate directory, and can also be
> called by web server threads for each Web API call made by a JHS client. In
> cases where there are many concurrent Web API calls/connections to JHS, all
> but one thread are blocked on the lock on the user directory. Eventually,
> client connects will time out, but the threads in JHS will not be killed and
> leave a lot of TCP connections in CLOSE_WAIT state.
> {noformat}
> [systest@vb1120 ~]$ sudo netstat -nap | grep 63729 | sort -k 4
> tcp0 0 10.17.202.19:10020 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:10020 10.17.198.30:33010
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.200.30:33980
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.202.10:59625
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10020 10.17.202.13:35765
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:10033 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:19888 0.0.0.0:*
> LISTEN 63729/java
> tcp0 0 10.17.202.19:19888 10.17.198.30:35103
> ESTABLISHED 63729/java
> tcp 277 0 10.17.202.19:19888 10.17.198.30:43670
> ESTABLISHED 63729/java
> tcp0 0 10.17.202.19:19888 10.17.198.30:45453
> ESTABLISHED 63729/java
> tcp 277 0 10.17.202.19:19888 10.17.198.30:49184
> ESTABLISHED 63729/java
> tcp1 0 10.17.202.19:19888 10.17.202.13:49992
> CLOSE_WAIT 63729/java
> tcp 261 0 10.17.202.19:19888 10.17.202.13:52703
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52707
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52708
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52710
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52714
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52723
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52726
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52727
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52739
> CLOSE_WAIT 63729/java
> tcp 261 0 10.17.202.19:19888 10.17.202.13:52749
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52753
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52757
> CLOSE_WAIT 63729/java
> tcp 256 0 10.17.202.19:19888 10.17.202.13:52760
> CLOSE_WAIT 63729/java
> tcp 256 0
[jira] [Commented] (MAPREDUCE-4285) Code sample in Tool javadocs is broken
[
https://issues.apache.org/jira/browse/MAPREDUCE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260084#comment-15260084
]
Gergely Novák commented on MAPREDUCE-4285:
--
Submitted a patch with an updated example code that does compile on trunk.
> Code sample in Tool javadocs is broken
> --
>
> Key: MAPREDUCE-4285
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4285
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv1
>Affects Versions: 1.0.3
>Reporter: Steve Loughran
>Priority: Minor
> Attachments: MAPREDUCE-4285.001.patch
>
>
> The javadocs in {{org.apache.hadoop.util.Tool}} contain an example to use the
> tool runner to invoke a tool.
> If you copy and paste the example into a java file it doesn't even compile
> # {{job.setInputPath()}} isn't there
> # {{job.setOutputPath()}} isn't there
> # {{job.waitForCompletion()}} isn't invoked
> # the {{Tool.run()}} implementation doesn't contain a return statement.
> The processed javadocs are online:
> [http://hadoop.apache.org/common/docs/r1.0.3/api/org/apache/hadoop/util/Tool.html]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MAPREDUCE-4285) Code sample in Tool javadocs is broken
[
https://issues.apache.org/jira/browse/MAPREDUCE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gergely Novák updated MAPREDUCE-4285:
-
Status: Patch Available (was: Open)
> Code sample in Tool javadocs is broken
> --
>
> Key: MAPREDUCE-4285
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4285
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv1
>Affects Versions: 1.0.3
>Reporter: Steve Loughran
>Priority: Minor
> Attachments: MAPREDUCE-4285.001.patch
>
>
> The javadocs in {{org.apache.hadoop.util.Tool}} contain an example to use the
> tool runner to invoke a tool.
> If you copy and paste the example into a java file it doesn't even compile
> # {{job.setInputPath()}} isn't there
> # {{job.setOutputPath()}} isn't there
> # {{job.waitForCompletion()}} isn't invoked
> # the {{Tool.run()}} implementation doesn't contain a return statement.
> The processed javadocs are online:
> [http://hadoop.apache.org/common/docs/r1.0.3/api/org/apache/hadoop/util/Tool.html]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MAPREDUCE-6687) Allow specifing java home via job configuration
[ https://issues.apache.org/jira/browse/MAPREDUCE-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260083#comment-15260083 ] Jason Lowe commented on MAPREDUCE-6687: --- This can already be accomplished by setting the appropriate value for JAVA_HOME in mapreduce.map.env and mapreduce.reduce.env or mapred.child.env for the tasks and yarn.app.mapreduce.am.env for the ApplicationMaster. > Allow specifing java home via job configuration > --- > > Key: MAPREDUCE-6687 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6687 > Project: Hadoop Map/Reduce > Issue Type: New Feature > Components: applicationmaster >Reporter: He Tianyi >Priority: Minor > > Suggest allowing user to use a preferred JVM implementation (or version) by > specifying java home via JobConf, to launch Map/Reduce tasks. > Especially useful for running A/B tests on real workload or benchmark between > JVM implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MAPREDUCE-4285) Code sample in Tool javadocs is broken
[
https://issues.apache.org/jira/browse/MAPREDUCE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gergely Novák updated MAPREDUCE-4285:
-
Attachment: MAPREDUCE-4285.001.patch
> Code sample in Tool javadocs is broken
> --
>
> Key: MAPREDUCE-4285
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4285
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv1
>Affects Versions: 1.0.3
>Reporter: Steve Loughran
>Priority: Minor
> Attachments: MAPREDUCE-4285.001.patch
>
>
> The javadocs in {{org.apache.hadoop.util.Tool}} contain an example to use the
> tool runner to invoke a tool.
> If you copy and paste the example into a java file it doesn't even compile
> # {{job.setInputPath()}} isn't there
> # {{job.setOutputPath()}} isn't there
> # {{job.waitForCompletion()}} isn't invoked
> # the {{Tool.run()}} implementation doesn't contain a return statement.
> The processed javadocs are online:
> [http://hadoop.apache.org/common/docs/r1.0.3/api/org/apache/hadoop/util/Tool.html]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MAPREDUCE-6199) AbstractCounters are not reset completely on deserialization
[ https://issues.apache.org/jira/browse/MAPREDUCE-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J resolved MAPREDUCE-6199. Resolution: Fixed Uh sorry, the commit message timeline is confusing on this. This is indeed present in the trunk and branch-2.8/branch-2, was only reverted in branch-2.7. My bad - sorry for the noise - the addendum vs. 2.7 notes confused me :( Resetting to earlier state. > AbstractCounters are not reset completely on deserialization > > > Key: MAPREDUCE-6199 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6199 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Anubhav Dhoot >Assignee: Anubhav Dhoot > Fix For: 2.8.0 > > Attachments: mr-6199.001.patch, mr-6199.001.patch, mr-6199.002.patch > > > AbstractCounters are partially reset on deserialization. This patch > completely resets them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MAPREDUCE-5875) Make Counter limits consistent across JobClient, MRAppMaster, and YarnChild
[
https://issues.apache.org/jira/browse/MAPREDUCE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260027#comment-15260027
]
Harsh J commented on MAPREDUCE-5875:
Uh sorry, the commit message timeline is confusing on this. This is indeed
present in the trunk and branch-2.8/branch-2, was only reverted in branch-2.7.
My bad - sorry for the noise - the addendum vs. 2.7 notes confused me :(
Resetting to earlier state.
> Make Counter limits consistent across JobClient, MRAppMaster, and YarnChild
> ---
>
> Key: MAPREDUCE-5875
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5875
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: applicationmaster, client, task
>Affects Versions: 2.4.0
>Reporter: Gera Shegalov
>Assignee: Gera Shegalov
> Fix For: 2.8.0
>
> Attachments: MAPREDUCE-5875.v01.patch, MAPREDUCE-5875.v02.patch,
> MAPREDUCE-5875.v03.patch, MAPREDUCE-5875.v04.patch, MAPREDUCE-5875.v05.patch,
> MAPREDUCE-5875.v06.patch, MAPREDUCE-5875.v07.patch, MAPREDUCE-5875.v08.patch,
> MAPREDUCE-5875.v09.patch
>
>
> Currently, counter limits "mapreduce.job.counters.*" handled by
> {{org.apache.hadoop.mapreduce.counters.Limits}} are initialized
> asymmetrically: on the client side, and on the AM, job.xml is ignored whereas
> it's taken into account in YarnChild.
> It would be good to make the Limits job-configurable, such that max
> counters/groups is only increased when needed. With the current Limits
> implementation relying on static constants, it's going to be challenging for
> tools that submit jobs concurrently without resorting to class loading
> isolation.
> The patch that I am uploading is not perfect but demonstrates the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MAPREDUCE-5875) Make Counter limits consistent across JobClient, MRAppMaster, and YarnChild
[
https://issues.apache.org/jira/browse/MAPREDUCE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harsh J updated MAPREDUCE-5875:
---
Release Note: (was: This change was reverted from all releases.)
> Make Counter limits consistent across JobClient, MRAppMaster, and YarnChild
> ---
>
> Key: MAPREDUCE-5875
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5875
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: applicationmaster, client, task
>Affects Versions: 2.4.0
>Reporter: Gera Shegalov
>Assignee: Gera Shegalov
> Fix For: 2.8.0
>
> Attachments: MAPREDUCE-5875.v01.patch, MAPREDUCE-5875.v02.patch,
> MAPREDUCE-5875.v03.patch, MAPREDUCE-5875.v04.patch, MAPREDUCE-5875.v05.patch,
> MAPREDUCE-5875.v06.patch, MAPREDUCE-5875.v07.patch, MAPREDUCE-5875.v08.patch,
> MAPREDUCE-5875.v09.patch
>
>
> Currently, counter limits "mapreduce.job.counters.*" handled by
> {{org.apache.hadoop.mapreduce.counters.Limits}} are initialized
> asymmetrically: on the client side, and on the AM, job.xml is ignored whereas
> it's taken into account in YarnChild.
> It would be good to make the Limits job-configurable, such that max
> counters/groups is only increased when needed. With the current Limits
> implementation relying on static constants, it's going to be challenging for
> tools that submit jobs concurrently without resorting to class loading
> isolation.
> The patch that I am uploading is not perfect but demonstrates the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MAPREDUCE-6286) A typo in HistoryViewer makes some code useless, which causes counter limits are not reset correctly.
[
https://issues.apache.org/jira/browse/MAPREDUCE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harsh J resolved MAPREDUCE-6286.
Resolution: Fixed
Uh sorry, the commit message timeline is confusing on this. This is indeed
present in the trunk and branch-2.8/branch-2, was only reverted in branch-2.7.
My bad - sorry for the noise - the addendum vs. 2.7 notes confused me :(
Resetting to earlier state.
> A typo in HistoryViewer makes some code useless, which causes counter limits
> are not reset correctly.
> -
>
> Key: MAPREDUCE-6286
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6286
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: client
>Affects Versions: 2.6.0
>Reporter: zhihai xu
>Assignee: zhihai xu
> Fix For: 2.8.0
>
> Attachments: MAPREDUCE-6286.000.patch
>
>
> A typo in HistoryViewer makes some code useless and it causes counter limits
> are not reset correctly.
> The typo is
> Limits.reset(conf);
> We should use jobConf instead of conf.
> With the typo, the following code becomes useless:
> {code}
> final Path jobConfPath = new Path(jobFile.getParent(), jobDetails[0]
> + "_" + jobDetails[1] + "_" + jobDetails[2] + "_conf.xml");
> final Configuration jobConf = new Configuration(conf);
> jobConf.addResource(fs.open(jobConfPath), jobConfPath.toString());
> {code}
> The code wants to load the configuration from the Job configuration file and
> reset the Limits based on the new configuration loaded from the Job
> configuration file. But with the typo, the Limits are reset with the old
> configuration.
> So this typo is apparent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MAPREDUCE-6286) A typo in HistoryViewer makes some code useless, which causes counter limits are not reset correctly.
[
https://issues.apache.org/jira/browse/MAPREDUCE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harsh J reopened MAPREDUCE-6286:
Reopening this to set the right resolution state. Since the fix was reverted
and never added back (does not exist on trunk), the Fixed resolution is
incorrect.
> A typo in HistoryViewer makes some code useless, which causes counter limits
> are not reset correctly.
> -
>
> Key: MAPREDUCE-6286
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6286
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: client
>Affects Versions: 2.6.0
>Reporter: zhihai xu
>Assignee: zhihai xu
> Fix For: 2.8.0
>
> Attachments: MAPREDUCE-6286.000.patch
>
>
> A typo in HistoryViewer makes some code useless and it causes counter limits
> are not reset correctly.
> The typo is
> Limits.reset(conf);
> We should use jobConf instead of conf.
> With the typo, the following code becomes useless:
> {code}
> final Path jobConfPath = new Path(jobFile.getParent(), jobDetails[0]
> + "_" + jobDetails[1] + "_" + jobDetails[2] + "_conf.xml");
> final Configuration jobConf = new Configuration(conf);
> jobConf.addResource(fs.open(jobConfPath), jobConfPath.toString());
> {code}
> The code wants to load the configuration from the Job configuration file and
> reset the Limits based on the new configuration loaded from the Job
> configuration file. But with the typo, the Limits are reset with the old
> configuration.
> So this typo is apparent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (MAPREDUCE-6199) AbstractCounters are not reset completely on deserialization
[ https://issues.apache.org/jira/browse/MAPREDUCE-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J reopened MAPREDUCE-6199: This was reverted and never added back. Reopening to set the right state as it isn't "fixed". > AbstractCounters are not reset completely on deserialization > > > Key: MAPREDUCE-6199 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-6199 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Anubhav Dhoot >Assignee: Anubhav Dhoot > Fix For: 2.8.0 > > Attachments: mr-6199.001.patch, mr-6199.001.patch, mr-6199.002.patch > > > AbstractCounters are partially reset on deserialization. This patch > completely resets them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MAPREDUCE-5875) Make Counter limits consistent across JobClient, MRAppMaster, and YarnChild
[
https://issues.apache.org/jira/browse/MAPREDUCE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harsh J updated MAPREDUCE-5875:
---
Release Note: This change was reverted from all releases.
I'm unable to reset the state to reopened here due to the revert so am just
adding a release note instead to highlight it.
> Make Counter limits consistent across JobClient, MRAppMaster, and YarnChild
> ---
>
> Key: MAPREDUCE-5875
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5875
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: applicationmaster, client, task
>Affects Versions: 2.4.0
>Reporter: Gera Shegalov
>Assignee: Gera Shegalov
> Fix For: 2.8.0
>
> Attachments: MAPREDUCE-5875.v01.patch, MAPREDUCE-5875.v02.patch,
> MAPREDUCE-5875.v03.patch, MAPREDUCE-5875.v04.patch, MAPREDUCE-5875.v05.patch,
> MAPREDUCE-5875.v06.patch, MAPREDUCE-5875.v07.patch, MAPREDUCE-5875.v08.patch,
> MAPREDUCE-5875.v09.patch
>
>
> Currently, counter limits "mapreduce.job.counters.*" handled by
> {{org.apache.hadoop.mapreduce.counters.Limits}} are initialized
> asymmetrically: on the client side, and on the AM, job.xml is ignored whereas
> it's taken into account in YarnChild.
> It would be good to make the Limits job-configurable, such that max
> counters/groups is only increased when needed. With the current Limits
> implementation relying on static constants, it's going to be challenging for
> tools that submit jobs concurrently without resorting to class loading
> isolation.
> The patch that I am uploading is not perfect but demonstrates the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
