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
IndexOutOfBoundsException after update from 6.2 to 6.4 #34555
Comments
Pinging @elastic/es-search-aggs |
For reference, the forum discussion is here: https://discuss.elastic.co/t/indexoutofboundsexception-after-update-from-6-2-to-6-4/152670 This is the relevant bit of the stack trace:
... which is a bit scary, because it looks like a bug decoding norms in lucene. Does this happen even after a reindex? And if so, are you able to share the mappings and documents for this index so that we can reproduce this? |
The bug is in Elasticsearch, the
This should fix the issue you're seeing. By default the |
@jimczi Thanks, it works! However it is still a bug and I guess this is only a workaround. I wonder why this was not an issue on 6.2 version previously? Thank you very much! It was a real headache. 😃 |
Yes this is why I left the issue open. We need to fix the |
The nested agg can defer the collection of children if it is nested under another aggregation. In such case accessing the score in the children aggregation throws an error because the scorer has already advanced to the next parent. This change fixes this error by caching the score of the parent in the nested aggregation. Children aggregations that work on nested documents will be able to access the _score. Also note that the _score in this case is always the parent's score, there is no way to retrieve the score of a nested docs in aggregations. Closes elastic#35985 Closes elastic#34555
The nested agg can defer the collection of children if it is nested under another aggregation. In such case accessing the score in the children aggregation throws an error because the scorer has already advanced to the next parent. This change fixes this error by caching the score of the parent in the nested aggregation. Children aggregations that work on nested documents will be able to access the _score. Also note that the _score in this case is always the parent's score, there is no way to retrieve the score of a nested docs in aggregations. Closes #35985 Closes #34555
The nested agg can defer the collection of children if it is nested under another aggregation. In such case accessing the score in the children aggregation throws an error because the scorer has already advanced to the next parent. This change fixes this error by caching the score of the parent in the nested aggregation. Children aggregations that work on nested documents will be able to access the _score. Also note that the _score in this case is always the parent's score, there is no way to retrieve the score of a nested docs in aggregations. Closes #35985 Closes #34555
Hi,
I asked the following question at your discussion forum and it turned out that this might be an issue, so I was advised to open an issue here.
Elasticsearch version (
bin/elasticsearch --version
):6.4.2
JVM version (
java -version
):1.8.0_171
OS version (
uname -a
if on a Unix-like system):Ubuntu 18.04 LTS
Description of the problem:
I have a big multi search query which contains pretty complicated aggregations. Recently I updated the Elasticsearch version from 6.2 to 6.4 and when this query is executed using the official PHP package, I am getting an error message in my log file which it looks like this:
full_stack_trace.txt
I have 4 queries in my multi search query, from which only 2 of them are failing (those are the similar ones - one of those two is pasted bellow). The error is logged every time when the "option group" / "option" top hits aggregation need to be done.
query.txt
It is important to mention that this is not the case when I try to execute this query via Kibana. When executed through Kibana I receive correct results. Previously, on 6.2 version, this was not an issue at all.
I noticed that the problem appears at the last two top_hits aggregations. If I remove them, I receive correct results.
I had 1 node and 2 shards on my local machine when the problem actually appeared. When I increased the number of shards to 3 or 5, the problem disappeared.
I checked the the two indexes I am querying in my Kibana monitoring section and this is the strange thing I have noticed:
It is strange that I have only 28 indexed documents in index1 for real, so I am confused how this numbers are counted and what they actually represent?
I have a workaround for this problem with increasing the number of shards. But it's strange to allocate 5 shards because of two indexes with 28 and 112 documents stored in them in order to make those aggregations working.
Thanks
The text was updated successfully, but these errors were encountered: