Where in PR #37 we tried the solution of moving messages to S3 when the batch was too large, this has a disadvantage that there can be 11 overall calls to AWS SQS & S3 to deal with a batch.
This solution takes the approach of splitting the batch after the oversized messages have been pushed to S3. This may result in several batches being sent to SQS, and it requires merging send batch results together as well as manipulating the send batch request. However, it has two advantages:
The overall number of requests can be smaller than with the switching to S3 approach
There's no artificial storing of right-sized messages to S3, meaning that the consumer of the messages, does not have to make a second call to S3 for EVERY message sent in a batch.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
An alternative fix for #24
Where in PR #37 we tried the solution of moving messages to S3 when the batch was too large, this has a disadvantage that there can be 11 overall calls to AWS SQS & S3 to deal with a batch.
This solution takes the approach of splitting the batch after the oversized messages have been pushed to S3. This may result in several batches being sent to SQS, and it requires merging send batch results together as well as manipulating the send batch request. However, it has two advantages:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.