[jira] [Commented] (YARN-7919) Split timelineservice-hbase module to make YARN-7346 easier
[ https://issues.apache.org/jira/browse/YARN-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367604#comment-16367604 ] Josh Elser commented on YARN-7919: -- bq. In this case, hbase depends on jcodings-1.0-18 (directly) and jcodings-1.0.13 (transitively from joni). It is probably not a real problem given both versions are in the same 1.0.x release line. But hadoop always takes the conservative approach. Is there any downside to make hbase-client depend on the exactly same version, 1.0.13, of joni? It is more of a nice-to-have dependency hygiene. Hrm, this is the part that confuses me. HBase defining a dependency on jcoding-1.0.18 should override the transitive 1.0.13 dependency and prevent YARN from seeing it. Is YARN setting a direct dependency on the same version of jcodings for some reason? > Split timelineservice-hbase module to make YARN-7346 easier > --- > > Key: YARN-7919 > URL: https://issues.apache.org/jira/browse/YARN-7919 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineservice >Affects Versions: 3.0.0 >Reporter: Haibo Chen >Assignee: Haibo Chen >Priority: Major > Attachments: YARN-7919.00.patch, YARN-7919.01.patch, > YARN-7919.02.patch, YARN-7919.03.patch, YARN-7919.04.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-7919) Split timelineservice-hbase module to make YARN-7346 easier
[ https://issues.apache.org/jira/browse/YARN-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367571#comment-16367571 ] Josh Elser commented on YARN-7919: -- I'm struggling here. I don't understand what the problem is. HBase-2.0 depends on joni 2.1.11 and jcodings 1.0.18. The build failure is due to the enforcer-plugin you configured in YARN. > Split timelineservice-hbase module to make YARN-7346 easier > --- > > Key: YARN-7919 > URL: https://issues.apache.org/jira/browse/YARN-7919 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineservice >Affects Versions: 3.0.0 >Reporter: Haibo Chen >Assignee: Haibo Chen >Priority: Major > Attachments: YARN-7919.00.patch, YARN-7919.01.patch, > YARN-7919.02.patch, YARN-7919.03.patch, YARN-7919.04.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-2683) document registry config options
[
https://issues.apache.org/jira/browse/YARN-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14174648#comment-14174648
]
Josh Elser commented on YARN-2683:
--
I made some grammar/punctuation changes in addition to some clarity on the
ZooKeeper paths that [~ste...@apache.org] has [pulled into his feature
branch|https://github.com/steveloughran/hadoop-trunk/pull/4]
document registry config options
Key: YARN-2683
URL: https://issues.apache.org/jira/browse/YARN-2683
Project: Hadoop YARN
Issue Type: Sub-task
Components: api, resourcemanager
Affects Versions: 2.6.0
Reporter: Steve Loughran
Assignee: Steve Loughran
Attachments: YARN-2683-001.patch
Original Estimate: 1h
Remaining Estimate: 1h
Add to {{yarn-site}} a page on registry configuration parameters
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YARN-1304) Error starting AM: org.apache.hadoop.security.token.TokenIdentifier: Error reading configuration file
[ https://issues.apache.org/jira/browse/YARN-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965966#comment-13965966 ] Josh Elser commented on YARN-1304: -- Just ran into this one myself. In my case, I had inadvertently updated some hadoop jars after the NM was already running. When an MR went to look at the classpath, some of the jars weren't on local filesystem anymore, and it bailed out. Restarting the NM and verifying that all hadoop jars were present and readable were sufficient for me to work around this. Probably worthwhile to close this out without any more info. Error starting AM: org.apache.hadoop.security.token.TokenIdentifier: Error reading configuration file - Key: YARN-1304 URL: https://issues.apache.org/jira/browse/YARN-1304 Project: Hadoop YARN Issue Type: Bug Affects Versions: 2.2.0 Reporter: Bikas Saha -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1754) Container process is not really killed
[
https://issues.apache.org/jira/browse/YARN-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13910012#comment-13910012
]
Josh Elser commented on YARN-1754:
--
This is expected as OSX does not contain a {{setsid}} binary. If you make sure
a binary available, you should see containers freed on OSX.
Also see: YARN-76
Container process is not really killed
--
Key: YARN-1754
URL: https://issues.apache.org/jira/browse/YARN-1754
Project: Hadoop YARN
Issue Type: Bug
Components: nodemanager
Affects Versions: 2.2.0
Environment: Mac
Reporter: Jeff Zhang
I test the following distributed shell example on my mac:
hadoop jar
share/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.2.0.jar
-appname shell -jar
share/hadoop/yarn/hadoop-yarn-applications-distributedshell-2.2.0.jar
-shell_command=sleep -shell_args=10 -num_containers=1
And it will start 2 process for one container, one is the shell process,
another is the real command I execute ( here is sleep 10).
And then I kill this application by running command yarn application -kill
app_id
it will kill the shell process, but won't kill the real command process. The
reason is that yarn use kill command to kill process, but it won't kill its
child process. use pkill could resolve this issue.
IMHO, it is a very important case which will make the resource usage
inconsistency, and have potential security problem.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
