jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas Saurabh (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-8046) Result items are not always correctly counted against the configured read limit if a query uses a lucene index
Date Wed, 20 Feb 2019 01:26:00 GMT

    [ 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)

Mime
View raw message