Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Revert "Revert "Introduce HTTP timeout (#3041)""

This reverts commit 14711361a0cb6beb3a57766804c109ba6f3f87c0.

  1. … 8 more files in changeset.
Revert "Introduce HTTP timeout (#3041)"

This reverts commit 59153d58c906341cfe3b5bebbedf289e3def1e09.

  1. … 8 more files in changeset.
Introduce HTTP timeout (#3041)

Introduce HTTP connection and socket timeout

Fix https://github.com/gradle/gradle/issues/868

  1. … 8 more files in changeset.
Introduce HTTP connection and socket timeout

    • -0
    • +23
    ./internal/resource/transport/http/HttpTimeoutSettings.java
  1. … 13 more files in changeset.
Revert Http socket/connection timeouts for the release (#2879)

  1. … 14 more files in changeset.
Fix formatting issues found by checkstyle

  1. … 1 more file in changeset.
Add flag to allow untrusted ssl connections to build cache (#2790)

  1. … 7 more files in changeset.
Defines default HTTP connection and socket timeouts (#2757)

    • -0
    • +23
    ./internal/resource/transport/http/HttpTimeoutSettings.java
  1. … 14 more files in changeset.
Initialize http proxy settings on first use

By deferring this initialization, we avoid doing work when not required

and ensure that the system properties are set on the process before

being read.

  1. … 1 more file in changeset.
Replace usages of org.gradle.api.Nullable

With javax.annotation.Nullable.

  1. … 460 more files in changeset.
Rework fix for parallel downloads on authenticated repositories

This commit reworks the fix for authenticated repositories to use a queue of `HttpContext` instead of a thread local map.

The rationale for this change is that 2 subsequent requests are not necessarily executed on the same thread. This means that

if request 1 performed authentication, and request 2 is done some time later, but on a different thread, authentication is

going to be done again.

To avoid this, request 1 will ask for a context in a queue. If no context is available, a new one is added. Once the request

is done, the context is added back in the queue, making it availble for subsequent requests to pick up. Request 2 comes and

picks it from the queue, then authentication state can be reused.

This means that at most, we can re-authenticate as many times as there are concurrent requests. But in practice, it is likely

that we're going to reuse shared context.

This commit also adds an integration test proving that parallel downloads work with authenticated repositories.

  1. … 3 more files in changeset.
Fix synchronization in `HttpClientHelper`

This commit fixes the synchronization in `HttpClientHelper` which prevented parallel downloads from happening in case

of an authenticated repository. To fix it, the helper now maintains a map of thread to http context, as recommended

by the HttpClient team. We don't use the JDK thread-local map because we need to clear the contexts once we close

the helper, in order to avoid leaking memory.

Accept more date patterns for the expires cookie header

  1. … 2 more files in changeset.
Renamed a class.

  1. … 25 more files in changeset.
Moved a class to remove package cycle.

  1. … 21 more files in changeset.
Introduce a ExecutionScopeServices between BuildSession and Build scopes

- This isn't wired into anything, so no services actually work yet.

  1. … 30 more files in changeset.
Remove unused class

  1. … 1 more file in changeset.
Fix concurrency bug in `HttpClientHelper`

The HTTP context should not be shared by several requests, or it just breaks when requests are done in parallel.

This explains the failures seen with `NTLM` authentication, but not only: there were more failures with `BASIC`

authentication too (and probably random other failures).

This commit changes the `HttpContext` so that we create a new one per request, in case we don't use authentication,

and if we do, then requests cannot be done in parallel (until we find a proper fix). This removes the special case in

`HttpAuthenticationDependencyResolutionIntegrationTest`.

  1. … 4 more files in changeset.
Use DefaultHttpBuildCacheServiceFactory to create a build cache in test

+review REVIEW-6478

  1. … 1 more file in changeset.
Use the same HttpClient configuration for the HTTP build cache

+review REVIEW-6478

  1. … 7 more files in changeset.
Do not restrict simultaneous HTTP connections per host

The maximum number of simultaneous HTTP connections is configured

as 20, but previously this was further limited to 2 per 'route'.

This commit removes the per-route limit. The overall maximum

connections is unchanged.

Address code review comments

+review REVIEW-6323

  1. … 2 more files in changeset.
Ensure ExternalResourceReadResponse are correctly closed

Digged inside the code to find all code path leading to the

instantiation of ExternalResourceReadResponse class and verify the

resource is properly closed.

+review REVIEW-6323

  1. … 5 more files in changeset.
Fixed failing integration tests due to `null` being returned instead of a proper http response

  1. … 2 more files in changeset.
Merge branch 'max-age' of https://github.com/DanielThomas/gradle into DanielThomas-max-age

  1. … 7 more files in changeset.
Do not require password for truststore (#697)

Because it throws an apache http SSLInitializationException it was

misleading as to what was really the cause of a password being

required for the use of a custom truststore.

+review REVIEW-6256

  1. … 1 more file in changeset.
Improve error handling if Http Response has no content

We did get a NPE when an artifact repository returned `304`.

This should never happen but with this error handling we

at least see what went wrong.

  1. … 1 more file in changeset.
Close HttpResponse in finally block

GRADLE-3518

REVIEW-6201

Close responses from httpclient

Since Apache HttpClient 4.3 `(Closable)HttpResponse`s

need to be closed. Gradle has not been doing that after

the upgrade to HttpClient 4.4. This probably caused some

resource problems.

GRADLE-3518

  1. … 3 more files in changeset.
Merge pull request #690 from kiddouk:story/S3-repository-can-be-configured-to-authenticate-using-AWS-EC2-instance-metadata

S3 repository can authenticate using AWS EC2 instance metadata

* This is related to https://github.com/gradle/gradle/blob/c2dc9979706e6b3beca13f1de860834e9255fb1b/design-docs/finding-and-using-credentials.md#story-an-s3-repository-can-be-configured-to-authenticate-using-awss-ec2-instance-metadata

* Note that the AWS S3 Client implementation will now use the following

credentials (in this specific order)

- Environment (AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY,

AWS_SESSION_TOKEN)

- Java System Properties - aws.accessKeyId and aws.secretKey

- Credential profiles file at the default

location (~/.aws/credentials) shared by all AWS SDKs and the AWS CLI

- Instance Profile Credentials - delivered through the Amazon EC2

metadata service

* The implementation assumes that only ONE authentication can be used

per s3-resource at a time

* This patch enforces that each Authentication now declares

`requiresCredentials` to be explicit

Integration tests:

Note that we cannot mock the instance meta data since it uses the ip

169.254.169.254 so we mock the system properties that the client

CredentialsProviderChain will look for.

  1. … 21 more files in changeset.