It would seem that I’m running into an issue when using authenticated private Maven repository in combination with JDK 1.8.0_u66 (everything works as expected on 1.8.0_u51). The issue is the resolution time for configurations.
On 1.8.0_u51 each detached configuration (created by Spring boot) takes about 3ms to resolve according to profile build, however on newer version - each configuration takes 5s! That’s quite noticable as in my very simple project, there are over 80 detached configurations
For the same simple project, if configured for resolution either via mavenCentral() or jcenter() - compilation and dependency resolution is super fast no matter if I’m running 1.8.0_u51 or 1.8.0_u66 - still about 3ms per detached configuration.
This led me to assume that this had something to do with the authentication issue and SSL handshakes.
During debug build, I can see that on 1.8.0_u66 there is a ~5 second gap between the output “Found java system property ‘http.nonProxyHosts’…” and “Using credentials [user:…” while on 1.8.0_u51 all that happens within one millisecond.
17:04:19.838 [DEBUG] [org.gradle.internal.resource.transport.http.JavaSystemPropertiesProxySettings] Found java system property 'http.nonProxyHosts': local|*.local|169.254/16|*.169.254/16. Will ignore proxy settings for these hosts.
17:04:24.911 [DEBUG] [org.gradle.internal.resource.transport.http.HttpClientConfigurer] Using Credentials [username: ******] and NTLM Credentials [user: ******, domain: , workstation: MACBOOK] for authenticating against 'null:-1' using NTLM
17:04:24.911 [DEBUG] [org.gradle.internal.resource.transport.http.HttpClientConfigurer] Using Credentials [username: ******] for authenticating against 'null:-1' using null
I’m also not sure about what the “null:-1” is but the output is identical between both JDK versions. The only thing that differs is the time it takes. The above thing is repeated for every detached configuration being resolved.
We have our own maven repository (Artifactory) which requires authentication and is accessible only over HTTPS.
System information:
Mac OSX 10.11
Oracle JDK 8 (both 1.8.0_u51 and 1.8.0_u66 installed)
Gradle 2.9
As an additional information, it would seem that several people are hitting a bug on JDK 8 u60 in regard to performance of the following call (non-Gradle):
InetAddress.getLocalHost().getHostName()
After running a super quick test code below, the timing changes between different JDK versions seem to match well with what i’ve observed when it comes to a Gradle build.
package test;
import java.net.InetAddress;
import java.net.UnknownHostException;
public class NameLookUP {
public static void main(String[] args) {
String version = System.getProperty("java.version");
System.out.println(version);
Long start = System.currentTimeMillis();
for (int x=1;x<=100;x++) {
try {
InetAddress.getLocalHost().getHostName();
Long currentElapsed = System.currentTimeMillis() - start;
System.out.println("Iteration "+String.valueOf(x)+" current elapsed time "+String.valueOf(currentElapsed));
} catch (UnknownHostException e) {
e.printStackTrace();
}
}
Long finish = System.currentTimeMillis();
Long elapsed = finish - start;
System.out.println("Total test elapsed time :"+elapsed.toString());
}
}
Is it safe to assume that Gradle tries to use the hostname for something?
If i try to set the “temporary (hidden) property” http.auth.ntlm.workstation to anything (because that would make the function to return) = the speed is the way I would expect it to be. So it’s safe to say that it’s truly due to the problem with that function call.
Thanks, I think this will be benefitial to do even if this issue did not exist, to save up a bit of chatter (I know, now it’s micro-optimisation).
I believe I’ve found what causes Java to behave this way (it is computer settings related but must still be a bug in JDK as it did not cause issues on u51).
On OSX you can set HostName, LocalHostName and ComputerName via scutil --set <pref> <value>. Sometimes OSX decides to change your LocalHostName to add -1 or -2 tot he name when it faultly thinks the name is taken (might have soemthing with Bonjour to do).
Initially my HostName was set to macbook.local and LocalHostname to macbook (This is just like what most Macs would have). However,it would seem that later on OSX changed LocalHostName to macbook-3 - and this is where the issue arrises on 1.8.0_u66, where InetAddress.getLocalHost().getHostName(); Call takes 5 seconds instead of under a millisecond. By changing between macbook and macbook-3 on LocalHostName I can consistently reproduce the issue.
All in all this seems to be a purely JDK issue, not sure if much can be done from Gradle side to help users with this issue (besides the above-mentioned disabling of authentication scheme).
