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

Add async_search.submit to HLRC #53592

Merged
merged 28 commits into from
Mar 19, 2020
Merged

Conversation

cbuescher
Copy link
Member

This commit adds a new AsyncSearchClient to the High Level Rest Client which
initially supporst the submitAsyncSearch in its blocking and non-blocking
flavour. Also adding client side request and response objects and parsing code
to parse the xContent output of the client side AsyncSearchResponse together
with parsing roundtrip tests and a simple roundtrip integration test.

Relates to #49091

This commit adds a new AsyncSearchClient to the High Level Rest Client which
initially supporst the submitAsyncSearch in its blocking and non-blocking
flavour. Also adding client side request and response objects and parsing code
to parse the xContent output of the client side AsyncSearchResponse together
with parsing roundtrip tests and a simple roundtrip integration test.

Relates to elastic#49091
@cbuescher cbuescher added :Search/Search Search-related issues that do not fall into other categories :Core/Features/Java High Level REST Client v8.0.0 v7.7.0 labels Mar 16, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (:Search/Search)

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features (:Core/Features/Java High Level REST Client)

Copy link
Contributor

@jimczi jimczi left a comment

Choose a reason for hiding this comment

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

The change looks good to me. I left some comments but @javanna may want to take a look too.

@cbuescher
Copy link
Member Author

@jimczi thanks for the review, I pushed some updates and left a reply regarding changing the client-side SubmitAsyncSearchRequest constructor, let me know what you think.

@cbuescher
Copy link
Member Author

I pushed a change with a different ctor, I'm still not a fan of this but added it as a base for discussion.

Copy link
Contributor

@jimczi jimczi left a comment

Choose a reason for hiding this comment

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

I like the new ctr better, I also find it cleaner to not expose the raw search request. Can you explain why you're not happy with it ?

Copy link
Member

@javanna javanna 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 couple of comments but nothing major besides a question on exposing the inner search request. Thanks for picking this up!!!

/**
* Get the {@link SearchRequest} that this submit request wraps
*/
public SearchRequest getSearchRequest() {
Copy link
Member

Choose a reason for hiding this comment

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

I see that whether or not to expose the inner search request was discussed in previous reviews. I am confused though on what direction was chosen. I see that the getters and setters from the search request are copied to the async request, but the inner search request is still exposed through this getter and can be modified directly. Didn't we want to rather hide it from users?

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 to hide

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, I will look into that. Will make testing a bit more awkward though because I can't reuse some existing infra then.

Copy link
Contributor

Choose a reason for hiding this comment

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

package protected ? ;)

Copy link
Member Author

@cbuescher cbuescher Mar 18, 2020

Choose a reason for hiding this comment

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

Would work but then I need to move some classes around. I'd prefer that to adding all those getters to the submit request.

Copy link
Member Author

@cbuescher cbuescher Mar 18, 2020

Choose a reason for hiding this comment

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

package protected ? ;)

This is proving to be tricky. I cannot easily move the AsyncSearchRequestConverters out of the org.elasticsearch.client package since they need package private infra from RequestConverters. I can probably move the SubmitAsyncSearchRequest into that package though, will take a look what that would change.

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 pushed f686a50 which moves the new request and response classes into org.elasticsearch.client to be able to use a package protected getSearchRequest() to avoid all the boilerplate getters on the new request. I'm unsure what I like best, take a look and let me know which direction you are leaning.

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 no getter is safer. We also do have extra protection on the server side for unsupported values but I think the client should never allow to send unsupported values.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with Luca, we should avoid the getter on the search request. However, we should have a getter for all options that we expose so I don't see why you want to avoid them ? If we have a setter, we need to provide a way to access the value.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, I reverted that change back to the one where I removed getSearchRequest and added a bunch of getters.

SearchSourceBuilder sourceBuilder = new SearchSourceBuilder().query(QueryBuilders.matchAllQuery());
SubmitAsyncSearchRequest request = new SubmitAsyncSearchRequest(sourceBuilder, index);
// 2 sec should be enough to make sure we always complete right away
request.setWaitForCompletion(new TimeValue(2, TimeUnit.SECONDS));
Copy link
Member

Choose a reason for hiding this comment

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

this should work but it's also risky. What other options we have?

  1. increase the timeout even more to really make sure it's enough, though what is enough
  2. accept that we may get a response while the search is still running, in which case is_partial and is_final will have a different value? Maybe don't set cleanOnCompletion and assert that when the id is returned the search is running, and when the id is not returned, both flags are false.

I am not sure either way, maybe I would go for option 1.

Copy link
Contributor

Choose a reason for hiding this comment

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

We can also have a loop here when get is implemented that submits the initial request and use get until isRunning is false on the response ?

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'll go with 1.) then, staying on the save side. I will keep cleanOnCompletion though, currently thats the only way I can see to actually get an Id and I'd like to tests its deserialization etc... here if possible (will also need ids in a follow-up PR around get-API)

Copy link
Member Author

Choose a reason for hiding this comment

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

sorry, missed the previous comment. Loop sounds okay as well, getting a response thats not running any more isn't actually the problem, the oposite is tricky (getting a response with an Id, as I mentioned earlier). I don't need that here so will remove it but will need it later for get/delete API tests.

Copy link
Member Author

Choose a reason for hiding this comment

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

Just also realize I haven't implemented get yet in this PR, we could change this later to a loop with get if you agree?
I don't see the benefits over a long-enough wait time though, quite the oposite. I never got this call to not finish in the first call, neither locally nor on CI which is even faster.

Copy link
Member

Choose a reason for hiding this comment

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

I like the loop idea if it does not make things too complicated, it sounds doable.

Copy link
Member

Choose a reason for hiding this comment

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

it's fine to make this a loop later ;)

@cbuescher
Copy link
Member Author

@javanna thanks for the review, I pushed an update that should adress your comments, including hiding the wrapped inner SearchRequest. For that I unfortunately had to add a bunch of additional getters for all the affected parameters that need to be translated in the AsyncRequestConverter and tests. Let me know if you think its worth it.

Copy link
Member

@javanna javanna left a comment

Choose a reason for hiding this comment

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

left a few more comments. I like it. Only a couple of nits around the changes made to hide the search request

Christoph Büscher added 6 commits March 18, 2020 16:55
Currently we don't send values for the `pre_filter_shard_size` and
`max_concurrent_shard_requests` SearchRequest parameters over http when using
the High Level Rest Client. This change adds these parameters to the
RequestConverters and tests.
…est by making getSearchRequest() package private"

This reverts commit f686a50.
Copy link
Member

@javanna javanna left a comment

Choose a reason for hiding this comment

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

LGTM

@cbuescher
Copy link
Member Author

Thanks @javanna, I pushed updates around your latest comments. @jimczi do you want to take another look or does this look okay now and I can start trying to get this through CI finally?

Copy link
Contributor

@jimczi jimczi 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 some nit comments regarding the async search response parsing but the code looks good to me.

Copy link
Contributor

@jimczi jimczi 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 cbuescher merged commit dea6b7d into elastic:master Mar 19, 2020
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this pull request Mar 20, 2020
This commit adds a new AsyncSearchClient to the High Level Rest Client which
initially supporst the submitAsyncSearch in its blocking and non-blocking
flavour. Also adding client side request and response objects and parsing code
to parse the xContent output of the client side AsyncSearchResponse together
with parsing roundtrip tests and a simple roundtrip integration test.

Relates to elastic#49091
Backport of elastic#53592
cbuescher pushed a commit that referenced this pull request Mar 20, 2020
This commit adds a new AsyncSearchClient to the High Level Rest Client which
initially supporst the submitAsyncSearch in its blocking and non-blocking
flavour. Also adding client side request and response objects and parsing code
to parse the xContent output of the client side AsyncSearchResponse together
with parsing roundtrip tests and a simple roundtrip integration test.

Relates to #49091
Backport of #53592
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Search/Search Search-related issues that do not fall into other categories v7.7.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants