hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jian He (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7326) Some issues in RegistryDNS
Date Fri, 13 Oct 2017 21:54:00 GMT

    [ 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: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message