Creating cached artifact hangs on InetAddress.getLocalHost()

[lptr]

In some cases (TBD) with Gradle 5.6.3 the build hangs for about 5 seconds while packaging the first cache artifacts. The behavior cannot be reproduced with Gradle 5.5.

Thread dump reveals that the packaging is not started because we are waiting for determining the local hostname:

"Execution worker for ':'" #573 prio=5 os_prio=31 tid=0x00007fc435d65800 nid=0x1473f runnable [0x000070000668b000]
   java.lang.Thread.State: RUNNABLE
        at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
        at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
        at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
        at java.net.InetAddress.getLocalHost(InetAddress.java:1501)
        - locked <0x00000003c007cb28> (a java.lang.Object)
        at org.gradle.caching.internal.origin.OriginMetadataFactory.determineHostName(OriginMetadataFactory.java:85)
        at org.gradle.caching.internal.origin.OriginMetadataFactory.access$300(OriginMetadataFactory.java:32)
        at org.gradle.caching.internal.origin.OriginMetadataFactory$1.execute(OriginMetadataFactory.java:74)
        at org.gradle.caching.internal.packaging.impl.TarBuildCacheEntryPacker.packMetadata(TarBuildCacheEntryPacker.java:129)
        at org.gradle.caching.internal.packaging.impl.TarBuildCacheEntryPacker.pack(TarBuildCacheEntryPacker.java:121)
        at org.gradle.caching.internal.packaging.impl.GZipBuildCacheEntryPacker.pack(GZipBuildCacheEntryPacker.java:42)
        at org.gradle.caching.internal.command.BuildCacheCommandFactory$StoreCommand.store(BuildCacheCommandFactory.java:173)

The problem was seen on macOS Mojave. It could be reproduced with both Oracle 1.8.0_211 and also 11.0.5.

---

cc: @gradle/build-cache

[lptr]

We did make some changes to how the origin metadata is put together in 5.6, calling InetAddress.getLocalHost().getHostName() directly instead of using InetAddressFactory. But only the effective difference I can see is that we used to run InetAddress.getLocalHost().getHostName() in a synchronized block, and we don't do it anymore.

That said, the problem can be reproduced when only a single task is being packages, i.e. there are no concurrent calls to InetAddress.getLocalHost().getHostName(), and synchronized should not make a difference.

[lptr]

This is the root cause apparently: https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds

[lptr]

JDK bug: https://bugs.openjdk.java.net/browse/JDK-8143378

[lptr]

My best theory right now is that we already had this problem with Gradle 5.5 and earlier. The difference that brought the problem up with 5.6 is that we removed the synchronized block, thus we ran into this multiple times, and in such a case the bug actually results in much more severe (hence more noticeable) effects. For example, in a build scan with 16 concurrent workers the first 16 tasks took over a minute to complete because of this problem.

The workaround in the PR #11134 is to run hostname on macOS.

[wolfs]

The problem that resolving localhost on macOS can take very long is not new and there is a known workaround: https://docs.gradle.com/enterprise/gradle-plugin/#macos-sierra-bug

It seems like the change in 5.6 did make the problem worse. Still, applying the workaround should make the problem go away, since the access is much faster.

Are you saying that the workaround doesn't help any more with macOS Mojave?

[lptr]

The workaround works as always. However, it is not trivial to notice that you need the workaround. Indeed, it seems that many has been suffering from this problem unknowingly.

In some environments the /etc/hosts workaround cannot be applied, e.g. when internal policies prevent users from applying it. But even when it can be applied it is hard to consistently apply it for everyone affected (including CI and engineers's computers); not in the least because it's hard to detect who needs the workaround in the first place.

We can fix this in a way that the user doesn't need to learn about and then fix the problem, so let's just do that.