[ https://issues.apache.org/jira/browse/OAK-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772505#comment-16772505 ]
Vikas Saurabh commented on OAK-8046: ------------------------------------ [~tmueller], {quote} bq. I think there is a risk that hasRewound() isn't always called at the right moment I don't think I understand. Afaict, as long as FulltextPathCursor#next is the right place to log index traversal log then checking for hasRewound() in next() should be ok too, right? {quote} Ok, I understood what you meant (we need to check when {{lastDoc}} is null and before pulling another result that'd set {{lastDoc}} ) after I wrote the test. I've attached [^OAK-8046-take2.patch] which has {{rewoundCount}} instead of {{hasRewoud}}. I've added one test for compatV2 index. I am somehow not able to figure out compatV1 case. I'd add that case and another which asserts that we still fail for genuine cases where the query should've failed. > Result items are not always correctly counted against the configured read > limit if a query uses a lucene index > --------------------------------------------------------------------------------------------------------------- > > Key: OAK-8046 > URL: https://issues.apache.org/jira/browse/OAK-8046 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene > Affects Versions: 1.8.7 > Reporter: Georg Henzler > Assignee: Vikas Saurabh > Priority: Major > Attachments: OAK-8046-take2.patch, OAK-8046.patch > > > There are cases where an index is re-opened during query execution. In that > case, already returned entries are read again and skipped, so basically > counted twice. This should be fixed to only count entries once (see also [1]) > The issue most likely exists since the read limit was introduced with OAK-6875 > [1] > https://lists.apache.org/thread.html/dddf9834fee0bccb6e48f61ba2a01430e34fc0b464b12809f7dfe2eb@%3Coak-dev.jackrabbit.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)