-
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
Add async_search.submit to HLRC #53592
Conversation
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
Pinging @elastic/es-search (:Search/Search) |
Pinging @elastic/es-core-features (:Core/Features/Java High Level REST Client) |
client/rest-high-level/src/test/java/org/elasticsearch/client/asyncsearch/AsyncSearchIT.java
Outdated
Show resolved
Hide resolved
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.
The change looks good to me. I left some comments but @javanna may want to take a look too.
...-high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchRequest.java
Outdated
Show resolved
Hide resolved
...-high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchRequest.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/action/search/SearchResponse.java
Outdated
Show resolved
Hide resolved
...high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchResponse.java
Outdated
Show resolved
Hide resolved
...-high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchRequest.java
Outdated
Show resolved
Hide resolved
...high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchResponse.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/test/java/org/elasticsearch/client/asyncsearch/AsyncSearchIT.java
Outdated
Show resolved
Hide resolved
@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. |
I pushed a change with a different ctor, I'm still not a fan of this but added it as a base for discussion. |
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 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 ?
...-high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchRequest.java
Show resolved
Hide resolved
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 left a couple of comments but nothing major besides a question on exposing the inner search request. Thanks for picking this up!!!
client/rest-high-level/src/main/java/org/elasticsearch/client/AsyncSearchClient.java
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/RequestConverters.java
Show resolved
Hide resolved
.../rest-high-level/src/main/java/org/elasticsearch/client/asyncsearch/AsyncSearchResponse.java
Outdated
Show resolved
Hide resolved
/** | ||
* Get the {@link SearchRequest} that this submit request wraps | ||
*/ | ||
public SearchRequest getSearchRequest() { |
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 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?
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.
+1 to hide
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.
Okay, I will look into that. Will make testing a bit more awkward though because I can't reuse some existing infra then.
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.
package protected ? ;)
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.
Would work but then I need to move some classes around. I'd prefer that to adding all those getters to the submit request.
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.
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.
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 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.
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 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.
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 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.
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.
Ok, I reverted that change back to the one where I removed getSearchRequest
and added a bunch of getters.
...-high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchRequest.java
Outdated
Show resolved
Hide resolved
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)); |
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.
this should work but it's also risky. What other options we have?
- increase the timeout even more to really make sure it's enough, though what is enough
- 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.
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.
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 ?
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'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)
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.
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.
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.
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.
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 like the loop idea if it does not make things too complicated, it sounds doable.
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.
it's fine to make this a loop later ;)
@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. |
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.
left a few more comments. I like it. Only a couple of nits around the changes made to hide the search request
...-high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchRequest.java
Show resolved
Hide resolved
...-high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchRequest.java
Show resolved
Hide resolved
...-high-level/src/main/java/org/elasticsearch/client/asyncsearch/SubmitAsyncSearchRequest.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/AsyncSearchRequestConverters.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/AsyncSearchRequestConverters.java
Outdated
Show resolved
Hide resolved
…aking getSearchRequest() package private
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.
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.
LGTM
client/rest-high-level/src/main/java/org/elasticsearch/client/AsyncSearchClient.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/AsyncSearchRequestConverters.java
Outdated
Show resolved
Hide resolved
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 left some nit comments regarding the async search response parsing but the code looks good to me.
client/rest-high-level/src/main/java/org/elasticsearch/client/RequestConverters.java
Outdated
Show resolved
Hide resolved
.../rest-high-level/src/main/java/org/elasticsearch/client/asyncsearch/AsyncSearchResponse.java
Outdated
Show resolved
Hide resolved
.../rest-high-level/src/main/java/org/elasticsearch/client/asyncsearch/AsyncSearchResponse.java
Show resolved
Hide resolved
.../rest-high-level/src/main/java/org/elasticsearch/client/asyncsearch/AsyncSearchResponse.java
Outdated
Show resolved
Hide resolved
.../rest-high-level/src/main/java/org/elasticsearch/client/asyncsearch/AsyncSearchResponse.java
Outdated
Show resolved
Hide resolved
.../rest-high-level/src/main/java/org/elasticsearch/client/asyncsearch/AsyncSearchResponse.java
Outdated
Show resolved
Hide resolved
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.
LGTM, thanks @cbuescher !
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
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
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