-
Notifications
You must be signed in to change notification settings - Fork 7
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
Implement atomic append operation #843
Comments
ijsong
added a commit
that referenced
this issue
Jan 21, 2025
This PR modifies replicate task pool implementation for future refactoring that will resolve #843. - Deprecated `newReplicateTask` and `release` functions in favor of new implementations. - Added `replicateTaskPool` struct for simplified pool management. - Updated tests to use the new functions and ensure backward compatibility.
ijsong
added a commit
that referenced
this issue
Feb 3, 2025
This PR modifies replicate task pool implementation for future refactoring that will resolve #843. - Deprecated `newReplicateTask` and `release` functions in favor of new implementations. - Added `replicateTaskPool` struct for simplified pool management. - Updated tests to use the new functions and ensure backward compatibility.
ijsong
added a commit
that referenced
this issue
Feb 3, 2025
This PR modifies replicate task pool implementation for future refactoring that will resolve #843. - Deprecated `newReplicateTask` and `release` functions in favor of new implementations. - Added `replicateTaskPool` struct for simplified pool management. - Updated tests to use the new functions and ensure backward compatibility.
ijsong
added a commit
that referenced
this issue
Feb 7, 2025
This PR modifies replicate task pool implementation for future refactoring that will resolve #843. - Deprecated `newReplicateTask` and `release` functions in favor of new implementations. - Added `replicateTaskPool` struct for simplified pool management. - Updated tests to use the new functions and ensure backward compatibility.
ijsong
added a commit
that referenced
this issue
Feb 7, 2025
This commit introduces a commit wait task that represents an entire append batch, rather than individual log entries. This is a crucial step towards implementing atomic append operations. Previously, a separate commit wait task was created for each log entry in an append batch. This approach made it difficult to handle the batch atomically, as commit wait tasks were processed individually. With this change, a single commit wait task is created for the entire batch. This allows the committer to process the batch atomically, ensuring that either all log entries in the batch are committed or none are. This change also brings a slight performance improvement, as the committer now needs to process fewer tasks. However, no specific benchmarks have been performed to measure the exact gain. The client API does not yet support atomic append operations, and partial success/failure is still allowed. This will be addressed in a future update. This change is a major step towards resolving #843, which aims to implement atomic append operations.
ijsong
added a commit
that referenced
this issue
Feb 7, 2025
This commit deprecates the error field in AppendResult as a step towards implementing atomic append operations while maintaining backward compatibility. Previously, the Append RPC could return partial success/failure results, with some log entries in a batch being appended successfully and others failing. This was indicated by the error field in AppendResult. To support atomic append operations without breaking existing clients, the error field is deprecated instead of being removed completely. This change allows clients to continue using the error field for now, but they should be aware that it will be removed in a future release. Clients should start migrating to the new atomic append API as soon as possible. The following changes were made to deprecate the error field: - The error field in AppendResult is marked as deprecated in the protobuf definition. - The Append RPC implementation no longer populates the error field. The next step is to implement atomic append operations in the client API. This will enable clients to append multiple log entries atomically, which will help to resolve #843.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current Situation
Currently, Varlog's Append API writes payloads to disk by dividing them into batchlets and processing each independently. This can result in partial success/failure scenarios where some batchlets are successfully written while others fail. This leads to two main issues:
Proposed Solution
Implement an atomic append operation for the entire payload. Key changes include:
Expected Benefits
Challenges and Next Steps
Handling large payloads
Batch length limit settings
Maintaining backward compatibility
Performance impact assessment
API and client library updates
Documentation and communication
Discussion Points
Testing Plan
The text was updated successfully, but these errors were encountered: