Refactoring the core BatchManager to change how it handles batch entry failures.

[16lim21]

Motivation and Context

Currently failures in a batch entry are handled by returning an empty response of the same type as a successful response. Instead, we want to be able to handle failed batch entries by filling the returned response with an appropriate exception. Separately, the core BatchManager currently allows for an unlimited number of batchKeys and an unlimited number of requests to be buffered for each batchKey. We should limit this to prevent excessive memory usage and give customers the option to override these limits with a configurable value.

Description

In this PR, I am modifying the SqsBatchFunctions to return an exception for each batch entry that failed. The core BatchManager now either expects a normal response or an Exception, and when it encounters an exception, it completes the corresponding response exceptionally. I also modified the BatchOverrideConfiguration to accept configurable values for the BatchKey limit and BatchBuffer limit. Currently, exceeding this limit just returns an exception that is handled by the core BatchManager (handles it by completing the corresponding response exceptionally). However, how to properly handle this situation should definitely be changed. I propose that when the batchKey limit is reached, the batchingMap should remove the least recently used empty batchKey. Handling the batchBuffer limit should not remove any requests that are already buffered, instead it could maybe wait until more space opens up or return an exception directly to the customer to notify that the BatchBuffer is full.

Testing

Tests were refactored to test if exceptions were properly returned on batch entry failures. Additional tests were also added to test the functionality of the batchKey limit and batchBuffer limit being reached/exceeded.

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

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
9 Code Smells

83.2% Coverage
0.0% Duplication