Reindex share retry between hit sources #44203
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The client and remote hit sources had each their own retry mechanism, which would do the same. Supporting resiliency we would have to expand on the retry mechanisms and as a preparation for that, the retry mechanism is now shared such that each sub class is only responsible for sending requests and converting responses/failures to common format. Part of elastic#42612
henningandersen
added
>non-issue
v8.0.0
:Distributed Indexing/Reindex
|
Pinging @elastic/es-distributed |
|
@elasticmachine update-branch |
|
@elasticmachine update branch |
|
Failure looks idential to #43889 but for another test, |
Tim-Brooks
approved these changes
Aug 6, 2019
| /** | ||
| * Return a new listener that delegates failure/reject to original but forwards response to responseHandler | ||
| */ | ||
| default <X> RejectAwareActionListener<X> withResponseHandler(Consumer<X> responseHandler) { |
There was a problem hiding this comment.
My preference is for default to be used in a scenario where you are providing default behavior for an interface that some implementation might want to overwrite. This feels more like a helper static method such as:
static <X> RejectAwareActionListener<X> withResponseHandler(RejectAwareActionListener<X> errorDelegate, Consumer<X> responseHandler) {
// Implementation
}There was a problem hiding this comment.
I agree. Fixed in 07d4793
No intention to override witResponsseHandler method so static is more appropriate.
…rsen/elasticsearch into enhance_reindex_shared_retry
henningandersen
added a commit
to henningandersen/elasticsearch
that referenced
this pull request
Aug 8, 2019
The client and remote hit sources had each their own retry mechanism, which would do the same. Supporting resiliency we would have to expand on the retry mechanisms and as a preparation for that, the retry mechanism is now shared such that each sub class is only responsible for sending requests and converting responses/failures to common format. Part of elastic#42612
henningandersen
added a commit
that referenced
this pull request
Aug 8, 2019
The client and remote hit sources had each their own retry mechanism, which would do the same. Supporting resiliency we would have to expand on the retry mechanisms and as a preparation for that, the retry mechanism is now shared such that each sub class is only responsible for sending requests and converting responses/failures to common format. Part of #42612
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The client and remote hit sources had each their own retry mechanism,
which would do the same. Supporting resiliency we would have to expand
on the retry mechanisms and as a preparation for that, the retry
mechanism is now shared such that each sub class is only responsible for
sending requests and converting responses/failures to common format.
Part of #42612