Skip to content

HLRC: Add support for reindex rethrottling #33832

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

Merged
merged 2 commits into from
Sep 20, 2018

Conversation

cbuescher
Copy link
Member

This change adds support for rethrottling reindex requests to the
RestHighLevelClient.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

public final ListTasksResponse reindexRethrottle(RethrottleRequest rethrottleRequest, RequestOptions options) throws IOException {
return performRequestAndParseEntity(rethrottleRequest, RequestConverters::rethrottle, options, ListTasksResponse::fromXContent,
emptySet());
}
Copy link
Member Author

Choose a reason for hiding this comment

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

I wasn't sure if I should also include the analogous deleteByQueryRethrottle and updateByQueryRethrottle methods in this PR since I'm not sure how we want to expose the three rethrottling types. Maybe we just want a single method since I thin the Request/Response objects are mostly identical? They even target the same RestAction I think. On the other hand, if at any point in the future we want to untie those, maybe it makes sense to add separate method pairs for each flavour, wdyt?

Copy link
Member

Choose a reason for hiding this comment

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

I think we said we'd like to line the client up with the REST API. So, yes, I'd make all three of them.

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay, thanks. I'd probably prefer to that in a follow-up PR though then, its a bit of a copy/paste job but then we also need to add two more documentation cases.

@cbuescher
Copy link
Member Author

@elasticmachine run gradle build tests

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

I left a few minor things. Sorry I didn't get to this yesterday!

@@ -465,7 +465,8 @@ static Request reindex(ReindexRequest reindexRequest) throws IOException {
Params params = new Params(request)
.withRefresh(reindexRequest.isRefresh())
.withTimeout(reindexRequest.getTimeout())
.withWaitForActiveShards(reindexRequest.getWaitForActiveShards());
.withWaitForActiveShards(reindexRequest.getWaitForActiveShards())
.withRequestsPerSecond(reindexRequest.getRequestsPerSecond());
Copy link
Member

Choose a reason for hiding this comment

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

hmmmm - I think maybe this should be fixed on update by query and delete by query too.

Copy link
Member Author

Choose a reason for hiding this comment

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

I opened a separate PR for this change (#33808), can you review that one first and we can add this change there already? Its a bit unrelated to adding the rethrottle API so I factored it out.

Copy link
Member Author

Choose a reason for hiding this comment

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

I added this in a commit there.

Params withRequestsPerSecond(float requestsPerSecond) {
// the default in AbstractBulkByScrollRequest is Float.POSITIVE_INFINITY,
// but we don't want to add that to the URL parameters, instead we use -1
if (Float.isFinite(requestsPerSecond)) {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need to add it to the url at all if it is POSITIVE_INFINITY.

Copy link
Member Author

Choose a reason for hiding this comment

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

We seem to need to add something, because I got errors from RestRethrottleAction#prepareRequest if not setting the parameter at all. AbstractBaseReindexRestHandler.parseRequestsPerSecond seems to be happy with -1 though.

Copy link
Member

Choose a reason for hiding this comment

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

I think it only needs to add -1 to the rethrottle API. Reindex doesn't need it if it is the default. But I suppose it doesn't hurt to pass it. I withdraw my comment.

public final ListTasksResponse reindexRethrottle(RethrottleRequest rethrottleRequest, RequestOptions options) throws IOException {
return performRequestAndParseEntity(rethrottleRequest, RequestConverters::rethrottle, options, ListTasksResponse::fromXContent,
emptySet());
}
Copy link
Member

Choose a reason for hiding this comment

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

I think we said we'd like to line the client up with the REST API. So, yes, I'd make all three of them.

@@ -642,15 +655,16 @@ public void testReindex() throws IOException {
.build();
createIndex(sourceIndex, settings);
createIndex(destinationIndex, settings);
BulkRequest setRefreshPolicy = new BulkRequest()
.add(new IndexRequest(sourceIndex, "type", "1")
Copy link
Member

Choose a reason for hiding this comment

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

Indent these a bit more please!

@@ -642,15 +655,16 @@ public void testReindex() throws IOException {
.build();
createIndex(sourceIndex, settings);
createIndex(destinationIndex, settings);
BulkRequest setRefreshPolicy = new BulkRequest()
Copy link
Member

Choose a reason for hiding this comment

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

Could you name it bulkRequest or something like that?

@cbuescher
Copy link
Member Author

@nik9000 thanks for the review, I adressed some comments and will add a commit to #33808. Could you review that one first, this PR is somewhat based on that one.

Christoph Büscher added 2 commits September 20, 2018 15:37
This change adds support for rethrottling reindex requests to the
RestHighLevelClient.
@cbuescher
Copy link
Member Author

@nik9000 I merged #33808 and rebased on master, is there anything left to do on this PR? I would open another PR for the deleteByQuery and updateByQuery throttling.

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks!

@cbuescher cbuescher merged commit 77145bb into elastic:master Sep 20, 2018
cbuescher pushed a commit that referenced this pull request Sep 20, 2018
This change adds support for rethrottling reindex requests to the
RestHighLevelClient.
kcm pushed a commit that referenced this pull request Oct 30, 2018
This change adds support for rethrottling reindex requests to the
RestHighLevelClient.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants