Skip to content
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

Process seeding of split fate operations in batches #5404

Merged
merged 4 commits into from
Mar 21, 2025

Conversation

cshannon
Copy link
Contributor

Updates the Seeder in the Manager that handles seeding split fate ops to use a single thread and to submit multiple outstanding operations to be seeded together instead of individually in order to improve performance. The user fate store will now track outstanding fate operations and return a future for each pending operation that will be completed when the batch is submitted.

This closes #5160

Updates the Seeder in the Manager that handles seeding split fate ops to
use a single thread and to submit multiple outstanding operations to
be seeded together instead of individually in order to improve
performance. The user fate store will now track outstanding fate
operations and return a future for each pending operation that will be
completed when the batch is submitted.

This closes apache#5160
@cshannon cshannon requested a review from keith-turner March 16, 2025 17:00
@cshannon cshannon self-assigned this Mar 16, 2025
@cshannon cshannon added this to the 4.0.0 milestone Mar 16, 2025
@cshannon
Copy link
Contributor Author

cshannon commented Mar 16, 2025

I didn't add any new tests for this (at least not yet) because I figured the existing ITs would catch any issues. I'm going to kick off a full IT build now. Also, I deprecated the MANAGER_SPLIT_WORKER_THREADS property because it is no longer used but I was wondering if it was just ok to delete it. It might be nice to add a performance to try and compare, even if it's not run all the time.

@@ -461,6 +461,7 @@ public enum Property {
+ "indefinitely. Default is 0 to block indefinitely. Only valid when tserver available "
+ "threshold is set greater than 0.",
"1.10.0"),
@Deprecated(since = "4.0.0")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This property can be dropped instead of deprecated as it was introduced in main.

// to a conditional writer and any known results will be removed
// from the pending map. Unknown results will be re-attempted up
// to the maxAttempts count
for (int attempt = 0; attempt < maxAttempts; attempt++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this will continue to loop even after pending is empty, could add a check for that.

Suggested change
for (int attempt = 0; attempt < maxAttempts; attempt++) {
for (int attempt = 0; attempt < maxAttempts && !pending.isEmpty(); attempt++) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, i'll fix that

@cshannon cshannon merged commit 359712e into apache:main Mar 21, 2025
4 checks passed
@cshannon cshannon deleted the accumulo-5160-2 branch March 21, 2025 13:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve performance of seeding split fate operations
2 participants