-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Retry fetching follower global checkpoint when it fails. #34019
Retry fetching follower global checkpoint when it fails. #34019
Conversation
Pinging @elastic/es-distributed |
@@ -374,7 +374,7 @@ static long computeDelay(int currentRetry, long maxRetryDelayInMillis) { | |||
return Math.min(backOffDelay, maxRetryDelayInMillis); | |||
} | |||
|
|||
private static boolean shouldRetry(Exception e) { | |||
static boolean shouldRetry(Exception e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe fetchGlobalCheckpoint()
should be done in ShardFollowNodeTask
like we update mapping or fetch document from shard changes api then we don't need to make to method package protected and complete reuse the retry logic that exists in ShardFollowNodeTask
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the fence on this one. I understand your reasons but I feel that ShardFollowNodeTask is complicated enough so we shouldn't move things in there unless strictly needed. As far as I can tell, the amount of code stays the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, I'm still undecided. Lets leave it this way.
run the java11 tests |
@elasticmachine run gradle build tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Production code LGTM. Is there any way we can test this?
@@ -374,7 +374,7 @@ static long computeDelay(int currentRetry, long maxRetryDelayInMillis) { | |||
return Math.min(backOffDelay, maxRetryDelayInMillis); | |||
} | |||
|
|||
private static boolean shouldRetry(Exception e) { | |||
static boolean shouldRetry(Exception e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the fence on this one. I understand your reasons but I feel that ShardFollowNodeTask is complicated enough so we shouldn't move things in there unless strictly needed. As far as I can tell, the amount of code stays the same.
I think when |
* master: Use more precise does S3 bucket exist method (elastic#34123) LLREST: Introduce a strict mode (elastic#33708) [CCR] Adjust list retryable errors (elastic#33985) Fix AggregationFactories.Builder equality and hash regarding order (elastic#34005) MINOR: Remove some deadcode in NodeEnv and Related (elastic#34133) Rest-Api-Spec: Correct spelling in filter_path description (elastic#33154) Core: Don't rely on java time for epoch seconds formatting (elastic#34086) Retry errors when fetching follower global checkpoint. (elastic#34019) Watcher: Reenable watcher stats REST tests (elastic#34107) Remove special-casing of Synonym filters in AnalysisRegistry (elastic#34034) Rename CCR APIs (elastic#34027) Fixed CCR stats api serialization issues and (elastic#33983) Support 'string'-style queries on metadata fields when reasonable. (elastic#34089) Logging: Drop Settings from security logger get calls (elastic#33940) SQL: Internal refactoring of operators as functions (elastic#34097)
Closes #34016