Skip to content

Issue 7459: Hadoop can't create S3 client with latest AWS SDK#7520

Open
rtjd6554 wants to merge 60 commits into
developfrom
7459-Hadoop-S3-Client
Open

Issue 7459: Hadoop can't create S3 client with latest AWS SDK#7520
rtjd6554 wants to merge 60 commits into
developfrom
7459-Hadoop-S3-Client

Conversation

@rtjd6554

@rtjd6554 rtjd6554 commented Jun 24, 2026

Copy link
Copy Markdown
Collaborator

Make sure you have checked all steps below.

Issue

  • My PR fully resolves the following issues. I've referenced an issue in the PR title, for example "Issue 1234 - My
    Feature". Note that before an issue is finished, you can still make a pull request by raising a separate issue
    for your progress.

Tests

  • My PR adds the following tests based on our test strategy OR does not need testing for this extremely good reason:
    • Execution of existing test suite, primary focus has been around the integration tests that utilise s3client within it.
      E.g. DockerInstanceIT, TpchSchemaPartitionedInsertPartitioningEnabledIT or DataFusionCompactionRunnerLocalStackIT

Documentation

  • In case of new functionality, my PR adds documentation that describes how to use it, or I have linked to a
    separate issue for that below.
  • If I have added new Java code, I have added Javadoc that explains it following our conventions and style.
  • If I have added or removed any dependencies from the project, I have updated the NOTICES file.

@rtjd6554 rtjd6554 added the needs-reviewer Pull requests that need a reviewer to be assigned label Jul 1, 2026
@rtjd6554
rtjd6554 marked this pull request as ready for review July 1, 2026 12:01
@ca61688 ca61688 self-assigned this Jul 2, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of code added here, I know the ticket says the existing test covers everything for this ticket but are there any unit tests that could be added for this class?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a lot of coverage of this already. It's used in all the integration tests for code that uses Hadoop, although that's just against LocalStack.

I think if we run the full performance test suite against this branch before merging that's probably enough?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the PR description needs updating to clarify which tests have been run or need to be run.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do need to run the performance test suite against this branch before we can merge it, because we don't know how this affects performance, or if it's working for Spark in a deployed instance.

@patchwork01 patchwork01 Jul 17, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about it, the behaviour of applying the Hadoop configuration properties would be good to have unit tests for. Can we do that?

If I could see a direct one-to-one correspondence with the Hadoop equivalent of this class I'd be less worried. As it is, the diff between this and the Hadoop version isn't easily comparable.

Would you prefer to unit test the behaviour or make it a more direct copy of the Hadoop code?

Here's a link to the original thread if you're reading this in the review: #7520 (comment)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unit tests added

@ca61688

ca61688 commented Jul 2, 2026

Copy link
Copy Markdown
Collaborator

Overall looks good, one comment about if we can add more tests

@ca61688 ca61688 removed their assignment Jul 2, 2026
Comment thread java/common/parquet/src/main/java/sleeper/parquet/HadoopS3ClientFactory.java Outdated
Comment thread java/common/parquet/src/main/java/sleeper/parquet/HadoopS3ClientFactory.java Outdated
Comment thread java/common/parquet/src/main/java/sleeper/parquet/HadoopS3ClientFactory.java Outdated
Comment thread java/common/parquet/src/main/java/sleeper/parquet/HadoopS3ClientFactory.java Outdated

@patchwork01 patchwork01 Jul 17, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about it, the behaviour of applying the Hadoop configuration properties would be good to have unit tests for. Can we do that?

If I could see a direct one-to-one correspondence with the Hadoop equivalent of this class I'd be less worried. As it is, the diff between this and the Hadoop version isn't easily comparable.

Would you prefer to unit test the behaviour or make it a more direct copy of the Hadoop code?

Here's a link to the original thread if you're reading this in the review: #7520 (comment)

@rtjd6554 rtjd6554 removed their assignment Jul 20, 2026
@rtjd6554 rtjd6554 added the needs-reviewer Pull requests that need a reviewer to be assigned label Jul 20, 2026
@ca61688 ca61688 self-assigned this Jul 20, 2026
@ca61688 ca61688 removed their assignment Jul 20, 2026
import static org.apache.hadoop.fs.s3a.Constants.REQUEST_TIMEOUT;
import static org.assertj.core.api.Assertions.assertThat;

class HadoopS3ClientFactoryTest {

@patchwork01 patchwork01 Jul 20, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like most of the behaviour isn't covered by these tests yet?

There's quite a bit of logic in HadoopS3ClientFactory, and right now this is testing it can:

  1. Set fs.s3a.s3.client.factory.impl on a Hadoop configuration
  2. Apply an explicit endpoint override from S3ClientCreationParameters
  3. Apply configuration that's set via AWSClientConfig.createClientConfigBuilder (just the request timeout is tested, which might be okay)

These look good, but it just touches the fringes of the actual behaviour implemented in HadoopS3ClientFactory.

I think we could do with some combination of more tests, and/or a clearer equivalence between ours and the Hadoop implementation. Some of the other comments on this review address the equivalence between our code and the Hadoop implementation. I'd focus on testing the parts where our code is different.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More equivalance gone for

}

@Test
void shouldApplyRequestTimeoutFromConfiguration() throws Exception {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this behaviour is delegated to the Hadoop implementation in AWSClientConfig. I think we probably don't need to cover everything that's done via AWSClientConfig.createClientConfigBuilder, having one test like this looks good.

We could clarify the intention of this test to demonstrate that HadoopS3ClientFactory applies configuration to ClientOverrideConfiguration through AWSClientConfig. Maybe just add a comment explaining this?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment added.

clientOverrideConfigBuilder.addMetricPublisher(
new AwsStatisticsCollector(parameters.getMetrics()));
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the Hadoop implementation there's code here to set the retry policy. Should that still be here?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed, added Standard Retry strategy


@Override
public S3Client createS3Client(URI uri, S3ClientCreationParameters params) throws IOException {
return configureClientBuilder(S3Client.builder(), params, getConf(), uri.getHost())

@patchwork01 patchwork01 Jul 20, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of connection settings that were set on the HTTP client at this point in the Hadoop code, via AWSClientConfig.createHttpClientBuilder in AWSClientConfig.createConnectionSettings.

Those look like they probably matter. Can we replicate that configuration against the new AWS client? It doesn't look like this is resolved in the latest Hadoop, since they haven't updated the AWS SDK yet.

I think the proxy settings don't look like they matter to us, though I could be wrong about that.

This also applies to createS3AsyncClient.

}

@Override
public S3AsyncClient createS3AsyncClient(final URI uri, final S3ClientCreationParameters parameters) throws IOException {

@patchwork01 patchwork01 Jul 20, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please can these public methods be moved above the private methods, as described in our coding conventions: https://github.com/gchq/sleeper/blob/develop/docs/development/conventions.md#ordering-within-a-java-class

This would also match the ordering in the original Hadoop code. In general it would be nice if we can match the ordering of methods from the Hadoop version.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed

if (configuredRegion != null && !configuredRegion.isEmpty()) {
region = Region.of(configuredRegion);
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Hadoop implementation sets fipsEnabled on the builder here. Should that still be here?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed

}

if (endpoint != null) {
boolean endpointEndsWithCentral = endpointStr.endsWith(CENTRAL_ENDPOINT);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Hadoop implementation has some validation code here with checkArgument. Should that still be here?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed

}

private static Region getS3RegionFromEndpoint(final String endpoint,
final boolean endpointEndsWithCentral) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the logging has been stripped out of this method. Should that still be here?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logging was removed as part of simplification as little value would be gained.

}
return AwsHostNameUtils.parseSigningRegion(endpoint, "s3").orElse(null);
}
return Region.EU_WEST_2;

@patchwork01 patchwork01 Jul 20, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of this as the default region is duplicated between here and configureEndpointAndRegion. Please can we set this in one place?

In general, using eu-west-2 as the default region could cause problems for us because things could continue to work if the region is defaulted, just because it happens to match what we're using. This could hide real failures. It might be worth keeping Hadoop's default region instead, or failing completely if it would default?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed, defaulting back to us-east-2

final ClientOverrideConfiguration.Builder clientOverrideConfigBuilder = AWSClientConfig.createClientConfigBuilder(conf, AWS_SERVICE_IDENTIFIER_S3);

parameters.getHeaders().forEach((h, v) -> clientOverrideConfigBuilder.putHeader(h, v));

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the Hadoop implementation there's code here to set the requester pays header. Should that still be here?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed

@patchwork01 patchwork01 removed the needs-reviewer Pull requests that need a reviewer to be assigned label Jul 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Hadoop can't create S3 client with latest AWS SDK

3 participants