Skip to content

Add support for AwsResponseMetadata #701

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 20, 2018
Merged

Conversation

zoewangg
Copy link
Contributor

@zoewangg zoewangg commented Sep 13, 2018

Description

Add AwsResponseMetadata support to allow customers to retrieve metadata information such as requestId, hostId for debugging purpose.

see #670

streaming operation looks like the following:

    public <ReturnT> ReturnT getObject(GetObjectRequest getObjectRequest,
                                       ResponseTransformer<GetObjectResponse, ReturnT> responseTransformer) throws NoSuchKeyException, AwsServiceException,
                                                                                                                   SdkClientException, S3Exception {
        HttpResponseHandler<GetObjectResponse> responseHandler = new S3ResponseHandler<>(new GetObjectResponseUnmarshaller(),
                                                                                           new StaxOperationMetadata().withHasStreamingSuccessResponse(true));
        DefaultErrorResponseHandler errorResponseHandler = new DefaultErrorResponseHandler(exceptionUnmarshallers);
        return clientHandler.execute(
            new ClientExecutionParams<GetObjectRequest, GetObjectResponse>().withResponseHandler(responseHandler)
                                                                            .withErrorResponseHandler(errorResponseHandler).withInput(getObjectRequest)
                                                                            .withMarshaller(new GetObjectRequestMarshaller()), responseTransformer);
    }

non-streaming operation:

    public GetObjectAclResponse getObjectAcl(GetObjectAclRequest getObjectAclRequest) throws NoSuchKeyException,
                                                                                             AwsServiceException, SdkClientException, S3Exception {
        S3ResponseHandler<GetObjectAclResponse> responseHandler = new S3ResponseHandler<>(
            new GetObjectAclResponseUnmarshaller(), new StaxOperationMetadata().withHasStreamingSuccessResponse(false));
        DefaultErrorResponseHandler errorResponseHandler = new DefaultErrorResponseHandler(exceptionUnmarshallers);
        return clientHandler.execute(new ClientExecutionParams<GetObjectAclRequest, GetObjectAclResponse>()
                                         .withResponseHandler(responseHandler).withErrorResponseHandler(errorResponseHandler)
                                         .withInput(getObjectAclRequest).withMarshaller(new GetObjectAclRequestMarshaller()));
    }

Pending

  • Codegen changes are pending.

I've include the DefaultS3Client, S3ResponseMetadata, S3ResponseHanlder in the PR.

Proposed Codegen Changes:

    "customResponseMetadata": {
        "EXTENDED_REQUEST_ID" : "x-amz-id-2",
        "CLOUD_FRONT_ID" : "X-Amz-Cf-Id",
        "REQUEST_ID" : "x-amz-request-id"
    }

customResponseMetadata is a map of metadata key to header key. S3ResponseMetadata and S3ResponseHandler will be generated based on it.

Currently it only supports header, let me know if there are other places we can retrieve additional metadata.

  • Integ tests

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have read the README document
  • I have added tests to cover my changes
  • All new and existing tests passed
  • A short description of the change has been added to the CHANGELOG

License

  • I confirm that this pull request can be released under the Apache 2 license

@zoewangg zoewangg requested a review from shorea September 13, 2018 22:31
@millems
Copy link
Contributor

millems commented Sep 14, 2018

What does the customer experience look like, accessing the data?

I'd expect response.metadata().extendedRequestId() or something similar.

@zoewangg
Copy link
Contributor Author

Here's the test: https://github.com/aws/aws-sdk-java-v2/pull/701/files#diff-c598a7406fc83ad8b0cc5ff552173b69

Basically,

    private void verifyResponseMetadata(S3Response response) {
        S3ResponseMetadata s3ResponseMetadata = response.responseMetadata();
        assertThat(s3ResponseMetadata).isNotNull();
        assertThat(s3ResponseMetadata.metadata().size()).isEqualTo(3);
        assertThat(s3ResponseMetadata.requestId()).isNotEqualTo("UNKNOWN");
        assertThat(s3ResponseMetadata.extendedRequestId()).isNotEqualTo("UNKNOWN");
    }

yeah, responseMetadata() seems a bit verbose, will update it to metadata()

@millems
Copy link
Contributor

millems commented Sep 14, 2018

response.metadata().metadata() seems like stuttering. Is there a reason we need to expose a map view of the metadata?

@zoewangg
Copy link
Contributor Author

zoewangg commented Sep 14, 2018

Unfortunately, we cannot use metadata() because it conflicts with some response models that have metadata fields, such as GetObjectResponse.metadata(), I will keep responseMetadata for now unless anyone has better name.

Is there a reason we need to expose a map view of the metadata?

I thought it would be useful for customers who want to retrieve all metadata without doing multiple method calls. As to the naming, how about response.responseMetadata().rawData()? I guess we can also remove it for now and add it back if they ask.

@zoewangg
Copy link
Contributor Author

Removed the logic of subclassing of responsehandler to extract metadata since simpleDb is the only services has additional metadata and we no longer support simpledb in v2.

All headers are being put to the AwsResponseMetadata.metadata map.

  • Services with responsemetadata customization: a service specific ResponseMetadata that subclasses AwsResponseMetadata(abstract class) will be generated to expose specific metadata methods.

  • No customized response metadata all service responses are going to use DefaultAwsResponseMetadata which only has requestId() defined.

* data.
*/
protected void registerAdditionalMetadataExpressions(StaxUnmarshallerContext unmarshallerContext) {
if (!metadata.containsKey(AWS_REQUEST_ID)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this still needed if we put all headers into the map?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, this is still needed for ec2 because the requestId for it is extracted from xml.

import software.amazon.awssdk.services.kinesis.model.DescribeLimitsResponse;
import software.amazon.awssdk.services.kinesis.model.KinesisResponse;

public class KinesisResponseMetadataIntegrationTest extends AbstractTestCase {
Copy link
Contributor

Choose a reason for hiding this comment

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

Kinesis actually has an id-2 like S3. Can we customize for that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

+1

* Contains information needed to create a {@link StaxResponseHandler}.
*/
@SdkProtectedApi
public final class StaxOperationMetadata {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we move the unmarshaller into this param like class? Or do you wanna keep it separate to avoid including type params?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made it like this to follow the same pattern as json protocol.

public <T> JsonResponseHandler<T> createResponseHandler(
JsonOperationMetadata operationMetadata,
Unmarshaller<T, JsonUnmarshallerContext> responseUnmarshaller) {
return getSdkFactory().createResponseHandler(operationMetadata, responseUnmarshaller);

But we can move the unmarshaller into this class. Don't have strong opinions.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think I like the current pattern as it keeps the metadata object a simple POJO with no type params.

@zoewangg zoewangg force-pushed the zoewang-ResponseMetadata branch from 4529f5f to ad47a11 Compare September 19, 2018 21:54
@zoewangg zoewangg force-pushed the zoewang-ResponseMetadata branch from ad47a11 to 7ec5558 Compare September 19, 2018 23:58
@zoewangg zoewangg merged commit 35dd9b1 into master Sep 20, 2018
@zoewangg zoewangg deleted the zoewang-ResponseMetadata branch September 20, 2018 17:01
aws-sdk-java-automation added a commit that referenced this pull request Dec 12, 2019
…8308313e

Pull request: release <- staging/fd170742-9fef-4b30-810c-ee148308313e
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.

3 participants