[
https://issues.apache.org/jira/browse/OAK-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772742#comment-16772742
]
Thomas Mueller commented on OAK-8046:
-------------------------------------
> resetted counter is technically incorrect in context of "nrt"/"sync" results.
Hm, yes. I wonder if someone will open a new issue saying the limit is not
respected...
Could you add a system property as well so for such cases it's possible to
switch back to the old behavior?
> LOG.debug was changed to LOG.info
> I intentionally did that
Ah yes that makes sense!
> remote index can't have such a concept of rewound - we really cant give the
> guarantees in remote index that we give in local lucene.
I'm not quire sure, for remote indexes, the query could also be re-run, and
internally we could skip already seen entries.
I think in either case, re-running a query (Lucene or remote) slows things
down... I think iterating over large results should be avoided in the
application. Maybe we should even make the LOG message a warning later on...
> 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)
