Hi,

So, I reproduced the issue, albeit with one configuration change that I'm not sure whether is common or not.

Basically, I could see that lookups to any host with a ".local" suffix would use MDNS and if the local services are not active, then I see the packets being sent on the wire, no responses and a delay of 5 seconds before the lookup fails. Initially, this was not affecting localhost lookups which still use normal DNS and even when DNS not available, that was failing immediately and therefore no delay.

To make InetAddress.getLocalHost() fail with a 5 second delay, I had to add ".local" to the DNS search path of the system. That has the effect of attempting a MDNS lookup after the DNS lookup fails, and this delays the failure for 5 seconds.

One question is if this is a common network configuration, or is there some other way to cause it to happen?

Looking at the patch again, I think perhaps (assuming we want to make a change here) a different approach might be better. Quite a lot of work is happening in the lookupIfLocalhost() function and I think we should try to limit this being called to only the local hostname lookup path. This might require boolean flags being being passed down from the InetAddress.getLocalHost() call to indicate whether this is a local address lookup or not.

Thanks,
Michael


On 05/04/2019, 20:15, Nora Howard wrote:
Oh, another element is that to see the behavior, your local hostname has to not have an entry in /etc/hosts. Adding it is one of the workarounds. My /etc/hosts has a localhost entry that does not include the name my machine ends up with after boot.

I'm also on 10.13, so I don't think that's the issue per se.

When I run scutil --dns. I get a resolver that points to en01 with some names on my VPN, and a number of mdns registrations that all look like this, where the resolver number, the domain and the order change, but the rest of the fields stay the same.
resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300000



On Fri, Apr 5, 2019 at 10:14 AM Michael McMahon <michael.x.mcma...@oracle.com <mailto:michael.x.mcma...@oracle.com>> wrote:

    I've spent some time trying to reproduce this on 10.13 but have
    not been able.
    I have disabled all the services as suggested (including some
    additional)
    such that the dns-sd command produces no output "records" and also by
    disabling unicast DNS access.

    I wonder if there has been a change in 10.13 to workaround this
    problem
    as I don't see any delay or external MDNS lookups happening.
    .
    Could you send me the output of "scutil --dns" of your laptop?
    At the same time, I will ask some colleagues here who might be
    running 10.12
    to try it out.

    Thanks,
    Michael

    On 04/04/2019, 18:38, Nora Howard wrote:
    Here's the diff
    http://cr.openjdk.java.net/~tonyp/8170910/webrev.0/
    <http://cr.openjdk.java.net/%7Etonyp/8170910/webrev.0/>

    To setup an env to reproduce the issue, on a OSX machine with >=
    10.12, turn off services that register with mDNS. For my laptop,
    I had to turn off iTunes and General System Preferences, disable
    "Allow Handoff between this Mac and your iCloud services". You
    might have to restart. The reporter on the ticket said to run
    `dns-sd -lo -B _services._dns-sd._udp local` to see whether you
    have any running.

    The file I used for exercising the behavior looks like this

    import java.net.InetAddress;
    public class Test {
      public static void main(String[] args) throws Exception {
          for (int i=0;i<4;i++){
              long start = System.currentTimeMillis();
              InetAddress localHost = InetAddress.getLocalHost();
              System.out.println(localHost);
              System.out.println(System.currentTimeMillis() - start);
    }}}

    The output I get on my laptop when I've set things up this way
    looks like this on JDK 13 EA. The first call takes the full 5
    seconds and subsequent ones hit a cache.

    nhoward.local/10.0.0.3 <http://10.0.0.3>
    5044
    nhoward.local/10.0.0.3 <http://10.0.0.3>
    0
    nhoward.local/10.0.0.3 <http://10.0.0.3>
    0
    nhoward.local/10.0.0.3 <http://10.0.0.3>
    0

    On JDK 8, each request takes 5 seconds. JDK 8's address lookup
    cache works differently. It's localhost name cache expiry is 5
    seconds.



    On Thu, Apr 4, 2019 at 2:41 AM Michael McMahon
    <michael.x.mcma...@oracle.com
    <mailto:michael.x.mcma...@oracle.com>> wrote:

        Hi Nora,

        At first sight, the approach sounds reasonable to me. I'd
        like to see the patch
        and also do you have detailed instructions on how to
        reproduce the issue (the 5 second delay)?

        Thanks,
        Michael.

        On 03/04/2019, 17:46, Nora Howard wrote:
        I'd initially sent this to jdk-dev, but I was asked to move
        it to net-dev.

        On OSX 10.12 or later, when no mDNS services are registered,
        getaddrinfo fails on looking up localhost addresses[1]. The
        jdk’s current implementation falls back to getifaddrs after
        getaddrinfo fails[2]. When getaddrinfo fails in this way, it
        takes 5 seconds to fail [3]. This means that calls to
        InetAddress.getLocalHost() may take up to 5 seconds to run.

        I’d like to change the jdk’s behavior in this instance so
        that instead of falling back to calling getifaddrs after
        getaddrinfo fails, it instead calls getifaddrs first if
        we’re on OSX and the hostname is localhost’s.

        Doing this will eliminate the 5 second delay looking up
        localhost on machines with this network setup. When looking
        up non-localhost addresses, it’ll add a call to
        os:gethostname and a comparison.

        I’d like to get some feedback about whether this approach
        sounds reasonable, and some guidance about next steps. I’ve
        read the “how to contribute” page[4], and the “code review”
        guide[5].

        I’ve put together a patch that I’ve tested locally by
        turning off mDNS services on my local OSX machine and
        exercising the behavior. I’d like to submit patches that
        target dev trunk as well as the jdk 8 and 11 branches.

        References

        1.

            On a Macintosh running 10.12 or later, if there are no
            apps that have a mDNS services registered (for instance,
            iTunes) and there are no services selected in the
            Sharing System Preferences, then the getaddrinfo will fail.

        (https://bugs.openjdk.java.net/browse/JDK-8170910)

        2.
        
http://hg.openjdk.java.net/jdk/jdk/file/cd3b7ad53265/src/java.base/unix/native/libnet/Inet6AddressImpl.c#l252
        
http://hg.openjdk.java.net/jdk/jdk/file/cd3b7ad53265/src/java.base/unix/native/libnet/Inet4AddressImpl.c#l132
        (The lookupIfLocalhost function checks the passed hostname
        against os::get_host_name, and if they match, looks up via
        getifaddrs.)

        3. This comment describes how to reproduce the issue. I’ve
        reproduced it locally on jdk 8, 11 and 13 ea.
        
https://bugs.openjdk.java.net/browse/JDK-8170910?focusedCommentId=14038262&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14038262
        
<https://bugs.openjdk.java.net/browse/JDK-8170910?focusedCommentId=14038262&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14038262>

        4. https://openjdk.java.net/contribute/

        5. https://openjdk.java.net/guide/codeReview.html

        Thanks,
-- Nora



-- Nora



--
Nora

Reply via email to