[
https://issues.apache.org/jira/browse/HADOOP-17859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17403438#comment-17403438
]
Jeongin Ju commented on HADOOP-17859:
-------------------------------------
What I used to refer when writing patches are as follow:
1. [https://datatracker.ietf.org/doc/html/rfc6891]
- Originally, UDP DNS Response has 512 bytes limitation, but eDNS(Extended
DNS) can has larger payload as you said. However, as 6.2.5 on documents above
said, reassembling datagrams features can be burden on some system so maximum
4KB payload is recommended.
2. What I checked is that single request on registry DNS (ex: dig
regionserver-5.hbase.${ACCOUNT}.${OUR_DOMAIN}) does not require long response
as you said. However request over components on registry DNS (ex: dig
regionserver.hbase.${ACCOUNT}.${OUR_DOMAIN}) can return large response when
there are multiple regionserver components.
And I'll create github PR as you requested :) thanks!
> DNS Query on DNS Registry got connection timed out at times.
> ------------------------------------------------------------
>
> Key: HADOOP-17859
> URL: https://issues.apache.org/jira/browse/HADOOP-17859
> Project: Hadoop Common
> Issue Type: Bug
> Components: registry
> Reporter: Jeongin Ju
> Priority: Minor
> Fix For: 3.1.2
>
> Attachments: HADOOP-17859.001.patch
>
>
> DNS query on YARN Registry DNS got connection timed out at times.
>
> After checking logs on registry dns, we found the cause that size of UDP
> Response is greater than Preallocated Byte buffer(4096)
>
> We added failsafe case by returning input query with TC flag so that client
> can know they should retried using TCP protocol.
>
>
> We found the problem and patched our cluster on 3.1.2 but it seems trunk
> still has the same problem.
> I attached patch based on the trunk.
>
> Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
