-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Issue with sliced scroll using routing #27550
Comments
I think it’s expected as of today from how it’s implemented but we should really try to fix it to also work if there is more than one shard and routing is used, I agree it looks like a bug! Thanks for opening this issue |
Yes this is expected because only the total number of shards per index is used to perform the slicing. |
Pinging @elastic/es-search-aggs |
I've recently come across the same problem (at least I believe it is https://discuss.elastic.co/t/empty-slices-with-scan-scroll/127255). Is this issue being actively looked at, or is it seen as low priority? |
It's on my todo list, not high priority but I'll try to find some time in the coming days to work on a fix. |
This commit adds two new methods to ShardSearchRequest: * #numberOfShardsIndex() that returns the number of shards of this index that participates in the request. * #remapShardId() that returns the remapped shard id of this shard for this request. The remapped shard id is the id of the requested shard among all shards of this index that are part of the request. Note that the remapped shard id is equal to the original shard id if all shards of this index are part of the request. These informations are useful when the _search is executed with a preference (or a routing) that restricts the number of shards requested for an index. This change allows to fix a bug in sliced scrolls executed with a preference (or a routing). Instead of computing the slice query from the total number of shards in the index, this change allows to compute this number from the number of shards per index that participates in the request. Fixes elastic#27550
This commit propagates the preference and routing of the original SearchRequest in the ShardSearchRequest. This information is then use to fix a bug in sliced scrolls when executed with a preference (or a routing). Instead of computing the slice query from the total number of shards in the index, this commit computes this number from the number of shards per index that participates in the request. Fixes #27550
This commit propagates the preference and routing of the original SearchRequest in the ShardSearchRequest. This information is then use to fix a bug in sliced scrolls when executed with a preference (or a routing). Instead of computing the slice query from the total number of shards in the index, this commit computes this number from the number of shards per index that participates in the request. Fixes #27550
Hi all, first a quick disclaimer, I'm not entirely sure if the following is a bug or documentation issue. After reading the sliced scroll section from the scroll API docs I got the impression that sliced scroll is supposed to work when targeting a single shard.
Elasticsearch version (
bin/elasticsearch --version
): 5.5.2, but I've tested with elasticsearch 6 and reproduced the same behaviour.Plugins installed:
JVM version (
java -version
):OS version (
uname -a
if on a Unix-like system): I'm using elasticsearch official docker image.docker.elastic.co/elasticsearch/elasticsearch:5.5.2
Description of the problem including expected versus actual behavior:
I'm trying to perform a sliced scroll targeting only one shard through routing and elasticsearch is returning all the results in only one of the 2 slices.
I expect elasticsearch to slice the query/results across all slices, even when targeting one shard only.
Steps to reproduce:
I have created a small bash script to reproduce the problem, please find it here.
Here are my results when I run the script using 1 and 2 shards.
Using 1 shard
Elasticsearch returns 2 slices, splitting the query/results as expected.
Using 2 shards
Elasticsearch returns 2 slices, but doesn't split the query/results, returning all results in only one slice.
I hope this covers all details required to reproduce the issue and I apologise in case this is the expected behaviour and I'm missing something.
Regards,
Alisson Sales
The text was updated successfully, but these errors were encountered: