Skip to content

Fixed issue relating to cancelling scheduled flush and removing requests. #2636

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

Conversation

16lim21
Copy link
Contributor

@16lim21 16lim21 commented Aug 2, 2021

Motivation and Context

Code from the last PR removed requests in a way that was very unintuitive and hacky. This PR attempts to solve that issue by not only making it more intuitive in how it removes requests, but hopefully also makes the removal of requests more thread safe.

Description

Originally, entries in the BatchBuffer were removed only when the entry's corresponding response was completed. Since a request and response were tied together in a BatchingExecutionContext, this required some hacky manipulation of an AtomicInteger (numRequests) to prevent excessive and inefficient flushes triggered by buffer sizes greater than the configured maxBatchItems. To fix this, requests are now removed when checking if a buffer can be flushed (look at canManualFlush() and canScheduledFlush() methods in BatchBuffer). By putting these methods inside a flushLock as well, it removed the need for a separate CancellableFlush and ScheduledFlush class since these synchronized blocks ensured that a manual flush could not occur while a scheduled flush had completed.

Other changes in this PR involved refactoring the code and cleaning it up to make it more readable and intuitive. More unit tests were also added.

Testing

In addition to tests implemented in the last PR, more JUnit unit tests were added to test the functionality of the supplementary classes involved with BatchManager. This specifically involved tests for BatchUtils and the IdentifiableMessage class. An additional multi-threading unit test was also added to test how the BatchManager might operate when faced with a combination of scheduled and manual flushes.

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 30 commits July 13, 2021 14:28
…-explanatory. Also refactored sdk-core tests
@16lim21
Copy link
Contributor Author

16lim21 commented Aug 2, 2021

I forgot to sync my fork after the PR was approved so the number of commits in this PR is quite inflated. The changes since the last PR start with commit fcee2ad ("Removing isManual").

@16lim21 16lim21 force-pushed the feature/master/automatic-request-batching branch from 88a82e9 to a7965d7 Compare August 3, 2021 15:40
@16lim21
Copy link
Contributor Author

16lim21 commented Aug 3, 2021

Code smells reported by sonarcloud mostly 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). There is one major code smell for unused method parameters but this is because I am passing class types to the builder() method like what is done in the Waiters class.

@@ -159,14 +157,31 @@ public void scheduleFiveMessagesWithEachThreadToDifferentDestinations() {
checkThreadedResponses(requests, responses, sendRequestFutures);
executorService.shutdownNow();
}

@Test
public void periodicallySendMessagesWithTenThreadsToSameDestination() {
Copy link
Contributor

Choose a reason for hiding this comment

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

What behavior is this test trying to verify?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This might have been more of a debugging test to see how periodically sending requests would work (since it would involve a combination of scheduling and manually flushing the buffers).

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, sounds like this is not needed here if it's only used for debugging purpose

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should I still include this test since no other test verifies how periodically sending requests might work with the BatchManager?

@16lim21 16lim21 force-pushed the feature/master/automatic-request-batching branch from 4275334 to 3436043 Compare August 4, 2021 19:47
@sonarqubecloud
Copy link

sonarqubecloud bot commented Aug 4, 2021

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

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

82.6% 82.6% Coverage
0.0% 0.0% Duplication

@zoewangg zoewangg merged commit 00b2efc into aws:feature/master/automatic-request-batching Aug 5, 2021
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.

2 participants