Internal classes and RequestBatchManager Impelementation

[joviegas]

RequestManager Implementation details

Overview

The RequestManager is responsible for managing and executing batched requests in an efficient manner. It utilizes various batch managers to handle different types of requests such as sending messages, deleting messages, changing message visibility, and handling generic request batches. The design ensures that requests are processed in an optimized and scalable way by leveraging concurrent processing and batching techniques.

Classes

1. SendMessageBatchManager

• Purpose: Manages the batching and sending of messages to SQS.
• Key Responsibilities:
  • Collects messages to be sent.
  • Batches messages into the appropriate size.
  • Sends the batched messages to SQS.
  • Handles responses and errors for the batched requests.

2. RequestBatchManager

• Purpose: Manages generic request batching for various types of SQS operations.
• Key Responsibilities:
  • Aggregates individual requests.
  • Creates batches of requests based on configuration.
  • Executes batched requests.
  • Provides mechanisms for retrying failed requests.

3. RequestBatchBuffer

• Purpose: Buffers requests before they are batched and sent.
• Key Responsibilities:
  • Temporarily stores requests.
  • Provides methods to retrieve and clear buffered requests.
  • Ensures thread-safe operations for request storage and retrieval.

4. IdentifiableMessage

• Purpose: Represents a message with a unique identifier.
• Key Responsibilities:
  • Stores message content and unique identifier.
  • Provides methods to access message details.

5. DeleteMessageBatchManager

• Purpose: Manages the batching and deletion of messages from SQS.
• Key Responsibilities:
  • Collects messages to be deleted.
  • Batches delete requests.
  • Sends batched delete requests to SQS.
  • Handles responses and errors for the delete requests.

6. DefaultSqsAsyncBatchManager

• Purpose: Default implementation for managing asynchronous SQS batch operations.
• Key Responsibilities:
  • Provides a default mechanism for handling various SQS batch operations asynchronously.
  • Ensures efficient processing of batch requests.

7. ChangeMessageVisibilityBatchManager

• Purpose: Manages the batching and visibility timeout changes for SQS messages.
• Key Responsibilities:
  • Collects visibility change requests.
  • Batches visibility change requests.
  • Sends batched requests to SQS.
  • Handles responses and errors for the visibility change requests.

8. BatchingMap

• Purpose: Utility class for managing batching contexts and operations.
• Key Responsibilities:
  • Stores and manages batch contexts.
  • Provides methods for adding and retrieving batches.
  • Ensures thread-safe access to batch contexts.

9. BatchingExecutionContext

• Purpose: Execution context for batching operations.
• Key Responsibilities:
  • Manages the lifecycle of batch executions.
  • Provides context-specific configurations and state management.

10. RequestBatchConfiguration

• Purpose: Configuration class for request batching.
• Key Responsibilities:
  • Stores configuration settings for batching operations.
  • Provides methods to access and modify configuration settings.

Key Design Considerations

• Concurrency: The design ensures thread-safe operations using appropriate synchronization mechanisms.
• Scalability: Batching of requests allows for efficient handling of a large number of requests.
• Error Handling: Each batch manager includes mechanisms for handling and retrying failed requests.
• Flexibility: The use of different batch managers allows for easy extension and customization for various types of SQS operations.

Conclusion

The RequestManager design leverages batching and asynchronous processing to efficiently manage and execute SQS requests. The modular design with specific batch managers for different request types ensures flexibility and scalability, making it suitable for high-throughput applications.

License

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

[dagnir]

Overall, it seems like we're still carrying over some of complexity from the original feature that intended to support batching across multiple services. Since we know that this is all going to be SQS specific can we simplify this design further, knowing that we just need to support SQS?

[dagnir]

This is a strange pattern since these look like they're only used for DefaultSqsAsyncBatchManager. Any reason this isn't an abstract class instead?

[joviegas]

This had private constructor , anyways made it abstract now.

Do you want to make it abstract and make DefaultSqsAsyncBatchManager extend SqsBatchFunctions ?

[dagnir]

Why wouldn't it just return the response map instead of taking it as an argument?

[joviegas]

We need to keep the track of individual requests that were send and update those requests with its corresponding response. While sending we create unique ids for messages and while receiving we map it back.
Note that flushBuffer is done asynchronously and we are not returning any values but updating the CompletableFutures of the responses from the map, I can explain you this offline .

[joviegas]

Overall, it seems like we're still carrying over some of complexity from the original feature that intended to support batching across multiple services. Since we know that this is all going to be SQS specific can we simplify this design further, knowing that we just need to support SQS?

I removed the Generic Interface for BatchManager and will have sepaarte Batch Manager for Response and Request.
We still need the Generic for RequestBatch manger apis since we have 3 APIs in it , this complexity is still needed unless we decide we will break it out and do simple implementation as V1

[dagnir]

These should just be protected abstract methods:

    protected abstract CompletableFuture<BatchResponseT> batchAndSend(List<IdentifiableMessage<RequestT>> identifiedRequests,
                                                                      String batchKey);

    protected abstract String getBatchKey(RequestT request);

    protected abstract List<Either<IdentifiableMessage<ResponseT>, IdentifiableMessage<Throwable>>> mapBatchResponse(BatchResponseT batchResponse);

[joviegas]

done

[dagnir]

We shouldn't need these right? See comment above re: making these protected abstract methods

[joviegas]

yeap , removed these

[dagnir]

Should this be more generic now that batch managers could differ between services, e.g. where the actual FQCN, construct method, and argument are all specified? Maybe similar to the way the utilities() method is generated?

aws-sdk-java-v2/services/s3/src/main/resources/codegen-resources/customization.config

Line 285 in 4f967b9

"utilitiesMethod": {

[joviegas]

Since we are providing static method for BatchManager we cannot use the existing customizations also discussed in
#5321 (comment)

[sonarqubecloud]

Quality Gate passed

Issues
50 New issues
0 Accepted issues

Measures
0 Security Hotspots
81.4% Coverage on New Code
0.1% Duplication on New Code

See analysis details on SonarCloud