-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Fix resultcache multiple postaggregation restore #15402
Fix resultcache multiple postaggregation restore #15402
Conversation
for (int postPos = 0; postPos < query.getPostAggregatorSpecs().size(); postPos++) { | ||
resultRow.set(postAggregatorStart + postPos, results.next()); | ||
} |
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 am not sure if this can happen but to be on the safe side?
for (int postPos = 0; postPos < query.getPostAggregatorSpecs().size(); postPos++) { | |
resultRow.set(postAggregatorStart + postPos, results.next()); | |
} | |
for (int postPos = 0; postPos < query.getPostAggregatorSpecs().size(); postPos++) { | |
if (results.hasNext()) resultRow.set(postAggregatorStart + postPos, results.next()); | |
} |
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 the contract around here should be to restore the same row that it have saved into the cache - if its not able to do so; I think it should fail with an exception - if it doesn't do that wouldn't that cause incorrect results - or not?
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 was also going through this area for a different purpose, and indeed there's a check below this code that checks if both the iterators have been exhausted completely, so even with the above check, the code would fail below. However, the error message would be more descriptive, so I think we should add the check back, otherwise it would fail with a generic NoSuchElementException
exception
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.
not sure about the case you were thinking - but I'm afraid that check might not be that usefull for these cases; consider the following:
- lets have
- a
results
with{1 dim}+{1 aggs}+{1 postagg} = 3
- a
resultRow
with{1 dim}+{1 aggs}+{2 postagg} = 4
(for whatever reason ?) - since in these cases the system is already facing a serious error - I'm not sure what value a nicer error message will give - as such error could not be fixed easily for sure
- a
- I think a more reasonable check would be to ensure that
results.size() == resultRow.size()
- so that we can remove the checking of all these iterators - as they are trying to do the same in a more complicated way
I've added an if
to throw an exception in case there are no next when there should be one; but all these conditionals are kinda redundant as the iterator was created for a list
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.
https://github.com/apache/druid/blob/master/processing/src/main/java/org/apache/druid/query/groupby/GroupByQueryQueryToolChest.java#L660
I was referring to this check. It should also handle the case that you mentioned above right? Perhaps adding the size check that you mentioned earlier is more legible. I am okay with the code either way.
while (postItr.hasNext() && results.hasNext()) { | ||
for (int postPos = 0; postPos < query.getPostAggregatorSpecs().size(); postPos++) { | ||
if (!results.hasNext()) { | ||
throw new ISE("Ran out of objects while reading postaggs from cache!"); |
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.
can use DruidException.defensive instead.
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've changed it to DruidException
- I was just following the error handling which was already in this method; there is another ISE
a few lines below and fetchAggregatorsFromCache
also throws an ISE
Fixes apache#15393 (cherry picked from commit dff5bcb)
Thank you @LakshSingla and @abhishekagarwal87 for reviewing and merging the changes! |
See #15393 for more details