Skip to content

Conversation

@muskan1012
Copy link
Contributor

Description of PR

Backported changes of PR [#6968] to 3.4 Branch.

How was this patch tested?

Tested by running locally.

slfan1989 and others added 30 commits January 11, 2024 10:18
…buted by Shilun Fan.

Reviewed-by: Steve Loughran <[email protected]>
Signed-off-by: He Xiaoqiao <[email protected]>
(cherry picked from commit 0f8b74b)
…ibuted by He Xiaoqiao.

Signed-off-by: Shuyan Zhang <[email protected]>
Signed-off-by: Shilun Fan <[email protected]>
Signed-off-by: Ayush Saxena <[email protected]>
(cherry picked from commit 9634bd3)
…sSystemImpl changes. (apache#6450) Contributed by Shilun Fan.

Reviewed-by: Steve Loughran <[email protected]>
Signed-off-by: Shilun Fan <[email protected]>
apache#2998)" (apache#6457) Contributed by Shilun Fan.

This reverts commit c1bf3cb.

Reviewed-by: Takanobu Asanuma <[email protected]>
Reviewed-by: He Xiaoqiao <[email protected]>
Reviewed-by: Ayush Saxena <[email protected]>
Reviewed-by: Viraj Jasani <[email protected]>
Signed-off-by: Shilun Fan <[email protected]>
…buted by Shilun Fan.

Reviewed-by: Steve Loughran <[email protected]>
Reviewed-by: He Xiaoqiao <[email protected]>
Signed-off-by: Shilun Fan <[email protected]>
… by PJ Fanning.

Reviewed-by: He Xiaoqiao <[email protected]>
Reviewed-by: Steve Loughran <[email protected]>
Signed-off-by: Shilun Fan <[email protected]>
…ibuted by Ayush Saxena."

This reverts commit c04a17f.

Reverted from Branch-3.4, since this commit is relevant only for trunk.
…che#6324)


Move to the new auth flow based signers for aws. * Implement a new Signer Initialization Chain
* Add a new instantiation method
* Add a new test
* Fix Reflection Code for SignerInitialization

Contributed by Harshit Gupta
…xceptions (apache#6425)



Differentiate from "EOF out of range/end of GET" from
"EOF channel problems" through
two different subclasses of EOFException and input streams to always
retry on http channel errors; out of range GET requests are not retried.
Currently an EOFException is always treated as a fail-fast call in read()

This allows for all existing external code catching EOFException to handle
both, but S3AInputStream to cleanly differentiate range errors (map to -1)
from channel errors (retry)

- HttpChannelEOFException is subclass of EOFException, so all code
  which catches EOFException is still happy.
  retry policy: connectivityFailure
- RangeNotSatisfiableEOFException is the subclass of EOFException
  raised on 416 GET range errors.
  retry policy: fail
- Method ErrorTranslation.maybeExtractChannelException() to create this
  from shaded/unshaded NoHttpResponseException, using string match to
  avoid classpath problems.
- And do this for SdkClientExceptions with OpenSSL error code WFOPENSSL0035.
  We believe this is the OpenSSL equivalent.
- ErrorTranslation.maybeExtractIOException() to perform this translation as
  appropriate.

S3AInputStream.reopen() code retries on EOF, except on
 RangeNotSatisfiableEOFException,
 which is converted to a -1 response to the caller
 as is done historically.

S3AInputStream knows to handle these with
 read(): HttpChannelEOFException: stream aborting close then retry
 lazySeek(): Map RangeNotSatisfiableEOFException to -1, but do not map
  any other EOFException class raised.

This means that
* out of range reads map to -1
* channel problems in reopen are retried
* channel problems in read() abort the failed http connection so it
  isn't recycled

Tests for this using/abusing mocking.

Testing through actually raising 416 exceptions and verifying that
readFully(), char read() and vector reads are all good.

There is no attempt to recover within a readFully(); there's
a boolean constant switch to turn this on, but if anyone does
it a test will spin forever as the inner PositionedReadable.read(position, buffer, len)
downgrades all EOF exceptions to -1.
A new method would need to be added which controls whether to downgrade/rethrow
exceptions.

What does that mean? Possibly reduced resilience to non-retried failures
on the inner stream, even though more channel exceptions are retried on.

Contributed by Steve Loughran
…points (apache#6277)


Adds a new option `fs.s3a.endpoint.fips` to switch the SDK client to use
FIPS endpoints, as an alternative to explicitly declaring them.


* The option is available as a path capability for probes.
* SDK v2 itself doesn't know that some regions don't have FIPS endpoints
* SDK only fails with endpoint + fips flag as a retried exception; wit this
  change the S3A client should fail fast.
  PR fails fast.
* Adds a new "connecting.md" doc; moves existing docs there and restructures.
* New Tests in ITestS3AEndpointRegion

bucket-info command support:

* added to list of path capabilities
* added -fips flag and test for explicit probe
* also now prints bucket region
* and removed some of the obsolete s3guard options
* updated docs

Contributed by Steve Loughran
…isk of Timeout waiting for connection from pool. (apache#6372)

HADOOP-19015.  Increase fs.s3a.connection.maximum to 500 to minimize the risk of Timeout waiting for connection from the pool

Contributed By: Mukund Thakur
…= false (apache#6441)


Add new option fs.s3a.checksum.validation, default false, which
is used when creating s3 clients to enable/disable checksum
validation.

When false, GET response processing is measurably faster.

Contributed by Steve Loughran.
…pache#6462) Contributed by Shilun Fan.

Reviewed-by: He Xiaoqiao <[email protected]>
Signed-off-by: Shilun Fan <[email protected]>
…r the release 3.4.0 (apache#6500) Contributed by Benjamin Teke.

Signed-off-by: Shilun Fan <[email protected]>
…e#6467)


This update ensures that the timeout set in fs.s3a.connection.request.timeout is passed down
to calls to CreateSession made in the AWS SDK to get S3 Express session tokens.

Contributed by Steve Loughran
… server calls (apache#6022)


Address JDK bug JDK-8314978 related to handling of HTTP 100
responses. 

https://bugs.openjdk.org/browse/JDK-8314978

In the AbfsHttpOperation, after sendRequest() we call processResponse()
method from AbfsRestOperation.
Even if the conn.getOutputStream() fails due to expect-100 error, 
we consume the exception and let the code go ahead.
This may call getHeaderField() / getHeaderFields() / getHeaderFieldLong() after
getOutputStream() has failed. These invocation all lead to server calls.

This commit aims to prevent this.
If connection.getOutputStream() fails due to an Expect-100 error,
the ABFS client does not invoke getHeaderField(), getHeaderFields(),
getHeaderFieldLong() or getInputStream().

getResponseCode() is safe as on the failure it sets the
responseCode variable in HttpUrlConnection object.

Contributed by Pranav Saxena
…#6470)



New test ITestCreateSessionTimeout to verify that the duration set
in fs.s3a.connection.request.timeout is passed all the way down.

This is done by adding a sleep() in a custom signer and verifying
that it is interrupted and that an AWSApiCallTimeoutException is
raised.

+ Fix testRequestTimeout()
* doesn't skip if considered cross-region
* sets a minimum duration of 0 before invocation
* resets the minimum afterwards

Contributed by Steve Loughran

Cut out S3 Select
* leave public/unstable constants alone
* s3guard tool will fail with error
* s3afs. path capability will fail
* openFile() will fail with specific error
* s3 select doc updated
* Cut eventstream jar
* New test: ITestSelectUnsupported verifies new failure
  handling above

Contributed by Steve Loughran
…ll packets. (apache#6503). Contributed by farmmamba.

Signed-off-by: Takanobu Asanuma <[email protected]>
(cherry picked from commit 4f4b846)
Improves region handling in the S3A connector, including enabling cross-region support
when that is considered necessary.

Consult the documentation in connecting.md/connecting.html for the current
resolution process.

Contributed by Viraj Jasani
This is a followup to PR:
HADOOP-19045. S3A: Validate CreateSession Timeout Propagation (apache#6470)

Remove all declarations of fs.s3a.connection.request.timeout
in
- hadoop-common/src/main/resources/core-default.xml
- hadoop-aws/src/test/resources/core-site.xml

New test in TestAwsClientConfig to verify that the value
defined in fs.s3a.Constants class is used.

This is brittle to someone overriding it in their test setups,
but as this test is intended to verify that the option is not
explicitly set, there's no workaround.

Contributed by Steve Loughran
The option fs.s3a.classloader.isolation (default: true) can be set to false to disable s3a classloader isolation;

This can assist in using custom credential providers and other extension points.

Contributed by Antonio Murgia
pan3793 and others added 8 commits October 13, 2024 06:08
apache#7091)

Contributed by Cheng Pan.

Reviewed-by: Steve Loughran <[email protected]>
Signed-off-by: Shilun Fan <[email protected]>
…ainer for CapacityScheduler (apache#7065). Contributed by Tao Yang.

Reviewed-by: Syed Shameerur Rahman <[email protected]>
Signed-off-by: He Xiaoqiao <[email protected]>
… (apache#7118)

* HADOOP-19310. Add JPMS options required by Java 17+ (apache#7114) Contributed by Cheng Pan.

Reviewed-by: Attila Doroszlai <[email protected]>
Signed-off-by: Shilun Fan <[email protected]>
…ache#7006) (apache#7097)


This moves Hadoop to Apache commons-collections4.
Apache commons-collections has been removed and is completely banned from the source code.

Contributed by Nihal Jain
…file does not contain file scheme (apache#7113)

Contributed by Syed Shameerur Rahman
Mockito is now at a JDK-17 compatible version.

Contributed by Muskan Mishra
@muskan1012
Copy link
Contributor Author

Wrong branch

@muskan1012 muskan1012 deleted the HADOOP-19328 branch November 18, 2024 04:54
@muskan1012 muskan1012 restored the HADOOP-19328 branch November 18, 2024 04:57
@muskan1012 muskan1012 deleted the HADOOP-19328 branch November 18, 2024 04:57
@muskan1012 muskan1012 restored the HADOOP-19328 branch November 18, 2024 05:00
@muskan1012 muskan1012 deleted the HADOOP-19328 branch November 18, 2024 05:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.