Jvm takes a long time to resolve ip-address for lo

Question

I seem to have a problem with performance of "sbt test" after upgrading to macOS Sierra. On a previous version of OS X it took about 40-50 seconds to finish. macOS Sierra times are much higher than that. Last run I did was around 15 minutes. Compile times are about the same as on 'El Capitan'.

I'm the only one from my team to try this new macOS so I can't tell if it's only happening on my mac or is it a universal issue.

My colleague had a similar issue on Ubuntu and it was related with random number generation slowing down the tests - Slow service response Times : Java SecureRandom & /dev/random

Unfortunately, that didn't work for me. Originally I tried that on JDK 8u54 and then tried updating to JDK 8u102 and that didn't help as well.

P.S. I'm running Macbook Pro Mid-2015 2.8GHz i7, 16GB ram, 1TB SSD.

Answer 1

I had the same problem. Tomcat went from 15 seconds to 6 minutes to initialise spring context after the upgrade... disabling csrutils didn't solve the issue for me.

I solved the problem by adding my Mac hostname (i.e. Macbook.local, or whatever your Mac is called) on the /etc/hosts file mapped to the 127.0.0.1 address as well as the ::1 like this:

127.0.0.1   localhost mbpro.local
::1         localhost mbpro.local

If you're interested you can find some details on the issue and solution here: https://thoeni.io/post/macos-sierra-java/

On the post I also link to a github project to help troubleshooting the issue and validating the solution.

The problem is related (I believe) on how the localhost name resolution works and how the java.net.InetAddr class is retrieving the addresses. I verified with few colleagues and apparently it doesn't happen to everyone who upgraded to Sierra, but I'm still investigating the roots of this change.

The solution anyway was the same that antid0te implemented and worked immediately.

Answer 2

It was a weird issue after installing the update to Mac Sierra 10.12 (16A323). In the hosts file with the below sorted the issue.

::1         localhost <myhostname>.local   <--- Was already present
127.0.0.1   localhost <myhostname>.local   <--- Solved the tomcat loading issue

You can get the myhostname by command $hostname anywhere in the terminal.

Answer 3

Enabling e.g. System Preferences > Sharing > Remote Login, results in the hostname being automatically assigned an IP address.

As people are seeing issues after the upgrade, it makes sense to assume that 10.12 changed how the hostname is resolved, i.e. at least with 10.11 the hostname is always resolved, while with 10.12 it is resolved only if a service is enabled in System Preferences > Sharing (someone with 10.11 could confirm this).

Answer 4

I have the same problem. My spring-boot application take 60 seconds to start on Sierra against 25 seconds on Yosemite.

While debugging, I realized that the problem comes from InetAddress.getLocalHost(). I changed my host file to add my hostname for 127.0.0.1 and :: 1 and now the application starts as fast as before.

Answer 5

The accepted answer helped me! Just adding this here explaining what I think the issue for me was:

My Hostname was something like "My Mac" which couldn't be resolved. In the settings it showed me that the computer could be addressed with mymac.local

I thought it was the space and renamed my mac to "my.mac" but even this didn't help since the dns automatically added was still mymac.local

Adding my.mac to the /etc/hosts helped then.

So my guess what the actual issue is: This only happens when your computer name contains anything that is not a letter. This is automatically removed by the os and then hostname and dns entry don't match. (which can be fixed my manually adding it)

Answer 6

I think it is a general problem with the new OS. I have a similar problem: I have a web application which is deployed to tomcat. On El Capitan it started up in 10 secs, now it takes 95 secs and the client (a Swing based desktop app) cannot connect to it (or at least it took lot of time). I think it is something around network communication, because a simple test console app runs well.