[
https://issues.apache.org/jira/browse/YARN-7326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204241#comment-16204241
]
Jian He commented on YARN-7326:
-------------------------------
Thanks [~aw],
bq. For 3) Integrate the yarn service commands into yarn application as
mentioned by Eric Yang.
I had a comment in
[here|https://issues.apache.org/jira/browse/YARN-7127?focusedCommentId=16200955&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16200955]
to explain the rationale. I do see the value of having coherent
user-experience. But, I also would like to see an elegant way to handle the
issues I mentioned there - mainly, two things:
1) Certain subcommands such as flex or upgrade won't be applicable to the
generic yarn app, they are specific to this custom framework AM. Will this
confuse users if we merge all these custom subcommands to the generic yarn app
command ?
2) For certain overloaded sub-commands such as status, it has different
meanings for the the app status from RM vs the status from customized AM. We
need a way to differentiate. Adding one more option may not seem friendly.
bq. 1) Actually integrate the docs with the rest of yarn-site. I'm not sure
what benefit there is of having a separate documentation section, especially
given #2 above and that the registrydns server could be used independently of
the REST API.
Sorry, didn't get this, which doc section are you referring to ? can you
clarify more ?
> Some issues in RegistryDNS
> --------------------------
>
> Key: YARN-7326
> URL: https://issues.apache.org/jira/browse/YARN-7326
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Jian He
> Assignee: Jian He
>
> [~aw] helped to identify these issues:
> Now some general bad news, not related to this patch:
> Ran a few queries, but this one is a bit concerning:
> {code}
> root@ubuntu:/hadoop/logs# dig @localhost -p 54 .
> ;; Warning: query response not set
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @localhost -p 54 .
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOTAUTH, id: 47794
> ;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#54(127.0.0.1)
> ;; WHEN: Thu Oct 12 16:04:54 PDT 2017
> ;; MSG SIZE rcvd: 12
> root@ubuntu:/hadoop/logs# dig @localhost -p 54 axfr .
> ;; Connection to ::1#54(::1) for . failed: connection refused.
> ;; communications error to 127.0.0.1#54: end of file
> root@ubuntu:/hadoop/logs#
> {code}
> It looks like it effectively fails when asked about a root zone, which is bad.
> It's also kind of interesting in what it does and doesn't log. Probably
> should be configured to rotate logs based on size not date.
> The real showstopper though: RegistryDNS basically eats a core. It is running
> with 100% cpu utilization with and without jsvc. On my laptop, this is
> triggering my fan.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
