Skip to content
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

Implementing BatchManager in sdk-core #2613

Conversation

16lim21
Copy link
Contributor

@16lim21 16lim21 commented Jul 21, 2021

Motivation and Context

The general batching solution in sdk-core will eventually allow for feature parity with v1 SQS buffered client as requested here. This will also streamline batch write operations for services that already support batch requests (ex. SQS with sendMessageBatch, Kinesis with putRecords).

Description

Implemented the core batch manager with generic functionality to automatically batch requests client-side. This PR mainly implements the sendRequest method that automatically buffers outgoing requests and flushes them when (a) a maxBatchItems limit is reached or (b) a timeout occurs as specified by the maxBatchOpenInMs parameter.

Testing

Changes were tested with two sets of junit tests. The first is a set of generic tests that are implemented in sdk-core. It passes arbitrary functions to the batch manager and is used to test the general functionality of the batch manager. This includes tests to see whether requests are flushed when reaching the maxBatchItems limit, whether timeouts work, and whether or not multi-threading would break the batch manager. A second set of tests are implemented in SQS to show how the batch manager might interact with an AWS service. These tests are essentially the same as the generic tests but the functions provided are SQS specific (ie they actually send the requests to SQS).

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
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

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

Michael Li added 22 commits July 13, 2021 14:28
…-explanatory. Also refactored sdk-core tests
Copy link
Contributor

@zoewangg zoewangg left a comment

Choose a reason for hiding this comment

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

  1. I think batchKey is better than batchGroupId, WDYT?
  2. Looks like GetBatchGroupIdFunction is missing from the PR. Let's fix it. Also, how about naming it BatchKeyMapper?

Copy link
Contributor

@zoewangg zoewangg left a comment

Choose a reason for hiding this comment

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

Overall LGTM. Good job! Just left a few very minor comments.

@sonarcloud
Copy link

sonarcloud bot commented Jul 28, 2021

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 75 Code Smells

69.9% 69.9% Coverage
0.0% 0.0% Duplication

@16lim21
Copy link
Contributor Author

16lim21 commented Jul 28, 2021

Code smells reported by sonarcloud are mostly not related to the change. The code smells that do relate to the changes made in this PR have to do with how I name some generics but those follow the style of the V2 SDK (ex. RequestT as opposed to just T).

@zoewangg zoewangg merged commit 329566c into aws:feature/master/automatic-request-batching Jul 28, 2021
aws-sdk-java-automation added a commit that referenced this pull request Jul 6, 2023
…1a6a0606f

Pull request: release <- staging/0d1d0d73-fb64-4c0d-82bd-9b21a6a0606f
Comment on lines +30 to +31
private volatile boolean isCancelled = false;
private volatile boolean hasExecuted = false;
Copy link

Choose a reason for hiding this comment

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

You don't need to make these variables volatile if you only access them using synchronized blocks.

See Java - is volatile required with synchronized? on StackOverflow and volatile fields in the Java Language Specification.

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