Gradle slow to resolve dependencies from artifactory

not-a-bug

(mrichar2) #1

Gradle Version: 2.12
Operating System: Windows 7
Is this a regression? If yes, which version of Gradle do you know it last worked for? No

When gradle fails to find an artifact in a public repo in articatory it hangs for a long time until timing out. I think I am hitting something like this Dependency resolution takes huge amount of time but unfortunately the bug that the last post mentions refers to a link that is no longer valid. In my case the artifacts are eventually resolved because we have a chain of ordered repositories that are hit. However resolution takes several magnitudes longer due to the timeout when hitting repositories that do not contain the artifact.

Using curl with the newest cygwin (2.5.1 curl 7.48.0) results in an error that says “curl: (18) transfer closed with 768 bytes remaining to read”

Observe that in the header response sent to curl the Content-Length header is 768 but no actual data is received.
This has come up for me every now and then. I used to sometimes comment repositories out to get it to work but would like to see if the actual issue can be fixed.
Gradle with --debug:

http://repository.company.com:8081/artifactory/public/com/company/eba/internal-artifacts/18/internal-artifacts-18.pom
17:13:47.289 [DEBUG] [org.gradle.internal.resource.transport.http.HttpClientHelper] Performing HTTP HEAD: http://repository.company.com:8081/artifactory/public/com/company/eba/internal-artifacts/18/internal-artifacts-18.pom
17:13:47.533 [DEBUG] [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected: default
17:13:47.549 [DEBUG] [org.apache.http.client.protocol.RequestAuthCache] Auth cache not set in the context
17:13:47.556 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection request: [route: {}->http://repository.company.com:8081][total kept alive: 0; route allocated: 0 of 2; total allocated: 0 of 20]
17:13:47.595 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection leased: [id: 0][route: {}->http://repository.company.com:8081][total kept alive: 0; route allocated: 1 of 2; total allocated: 1 of 20]
17:13:47.612 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Opening connection {}->http://repository.company.com:8081
17:13:47.630 [DEBUG] [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] Connecting to repository.company.com/:8081
17:13:47.667 [DEBUG] [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] Connection established <->
17:13:47.671 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request HEAD /artifactory/public/com/company/eba/internal-artifacts/18/internal-artifacts-18.pom HTTP/1.1
17:13:47.676 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: UNCHALLENGED
17:13:47.699 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED

Curl:

>curl -v -XHEAD http://<artifactoryurl>/artifactory/public/com/company/eba/ajar/0.LOCALD EV/jar-st
amper-0.LOCALDEV.jar
Warning: Setting custom HTTP method to HEAD with X/-request may not work the
Warning: way you want. Consider using I/-head instead.
STATE: INIT => CONNECT handle 0x600069bb0; line 1402 (connection #-5000)
Added connection 0. The cache now contains 1 members
Trying ::1...
STATE: CONNECT => WAITCONNECT handle 0x600069bb0; line 1455 (connection #0)
Trying 127.0.0.1...
Connected to localhost (127.0.0.1) port 3128 (#0)
STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600069bb0; line 1562 (connection #0)
STATE: SENDPROTOCONNECT => DO handle 0x600069bb0; line 1580 (connection #0)
> HEAD http://<artifactryurl>/artifactory/public/com/company/eba/ajar/0.LOCALD HTTP/1.1
> Host: <artifactryurl>
> User-Agent: curl/7.48.0
> Accept: /
>
STATE: DO => DO_DONE handle 0x600069bb0; line 1659 (connection #0)
STATE: DO_DONE => WAITPERFORM handle 0x600069bb0; line 1786 (connection #0)
STATE: WAITPERFORM => PERFORM handle 0x600069bb0; line 1796 (connection #0)
HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404 Not Found
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Content-Length: 775
<
transfer closed with 775 bytes remaining to read
multi_done
Closing connection 0
The cache now contains 0 members
curl: (18) transfer closed with 775 bytes remaining to read
Warning: Setting custom HTTP method to HEAD with X/-request may not work the
Warning: way you want. Consider using I/-head instead.
STATE: INIT => CONNECT handle 0x600069bb0; line 1402 (connection #-5000)
Added connection 1. The cache now contains 1 members
Hostname localhost was found in DNS cache
Trying ::1...
STATE: CONNECT => WAITCONNECT handle 0x600069bb0; line 1455 (connection #1)
Trying 127.0.0.1...
Connected to localhost (127.0.0.1) port 3128 (#1)
STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600069bb0; line 1562 (connection #1)
STATE: SENDPROTOCONNECT => DO handle 0x600069bb0; line 1580 (connection #1)
> HEAD http://EV/ajar-0.LOCALDEV.jar HTTP/1.1
> Host: EV
> User-Agent: curl/7.48.0
> Accept: /
>
STATE: DO => DO_DONE handle 0x600069bb0; line 1659 (connection #1)
STATE: DO_DONE => WAITPERFORM handle 0x600069bb0; line 1786 (connection #1)
STATE: WAITPERFORM => PERFORM handle 0x600069bb0; line 1796 (connection #1)
HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404 Not Found
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Content-Length: 768
<
transfer closed with 768 bytes remaining to read
multi_done
Closing connection 1
The cache now contains 0 members
curl: (18) transfer closed with 768 bytes remaining to read

(Cédric Champeau) #2

Hi Mark !

Do you have a firewall and antivirus installed? If yes, could you try temporarily disabling them and see how it goes? Could you produce a build scan for this issue so that we have a complete record?


(mrichar2) #3

After observing frames through wireshark I do not believe this is a Gradle problem so this can be closed. My mention and investigation of that other bug was a false lead. It seems to be network / server related as the HEAD & GET requests are sent out right away through gradle and the ACK is received right away but the actual response to the HEAD/GET takes on the order of seconds. I was confused at first since using curl takes miliseconds but that appears to be due to caching as hitting artifacts that the build was not resolving still took some time.