On 10/04/2019, 22:03, Bernd Eckenfels wrote:
Maybe instead of having a MacOS specific algorithm it would be a good
idea to have getLocalHostName generally look up the hostnames from the
Array with a trailing „.“ and only if that Fails have it search with
search Suffix?
Interesting idea. Though I think it doesn't change the fact that you are
querying the name service for
a name it won't resolve, and in this MDNS case, would end up waiting for
5 seconds for the result.
Also I think we talked before that removing AI_CANONNAME would also
help. (Especially since it does a reverse lookup itself anyway).
AI_CANONNAME doesn't do a reverse lookup. It just asks for the canonical
name to be returned as part of the
regular forward lookup, but which we don't use.
This shouldn't make any difference to the lookup because if the name
supplied is an alias, it still has to
be resolved to get the IP address of the desired name whether you use
the AI_CANONNAME flag or not.
Typically, the result for the alias and the cname record is returned in
the same response from the local DNS server.
You're probably thinking of the InetAddress.getCanonicalHostName()
method which does do a reverse lookup
(via getnameinfo())
Michael
*Von: *Michael McMahon <mailto:michael.x.mcma...@oracle.com>
*Gesendet: *Dienstag, 9. April 2019 18:35
*An: *Nora Howard <mailto:nhow...@twitter.com>
*Cc: *net-dev@openjdk.java.net <mailto:net-dev@openjdk.java.net>
*Betreff: *Re: JDK-8170910: Avoid 5 second localhost lookup behavior
on OSX
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
