Ordered batch support #866
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to increase the throughput of the transactional outbox by implementing batch processing for ordered items.
This significantly improves performance while maintaining ordering guarantees within topics.
Details
Batch Error Handling
The implementation uses an all-or-nothing approach for error handling in batch processing. When any entry in a batch fails during execution, the entire batch is marked for retry, maintaining strict ordering guarantees within topics. This approach ensures transactional consistency at the cost of potentially reduced throughput when problematic entries exist. Upon failure, the system increments attempt counts for all entries in the batch, triggers appropriate failure listeners, and rolls back the transaction. This guarantees that entries within a topic are always processed in sequence, even after failures. The batch will be retried according to the configured retry schedule until successful completion or until entries reach their maximum attempt threshold and become blocked. This simpler approach prioritizes correctness and ordering over partial processing, making the system more predictable when handling failures.
Important Notes
Submitterinterface and worked around that by using the sameExecutor. I assume we will have to change this in some way.Looking forward to feedback :)