Lucene - Core
  1. Lucene - Core
  2. LUCENE-3268

TestScoredDocIDsUtils.testWithDeletions test failure

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.4, 4.0-ALPHA
    • Component/s: modules/facet
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      ant test -Dtestcase=TestScoredDocIDsUtils -Dtestmethod=testWithDeletions -Dtests.seed=-2216133137948616963:2693740419732273624 -Dtests.multiplier=5

      In general, on both 3.x and trunk, if you run this test with -Dtests.iter=100 it tends to fail 2% of the time.

        Activity

        Hide
        Shai Erera added a comment -

        Committed revision 1142675 (3x).
        Committed revision 1142676 (trunk).

        Show
        Shai Erera added a comment - Committed revision 1142675 (3x). Committed revision 1142676 (trunk).
        Hide
        Shai Erera added a comment -

        Ok I found the problem. The test relies on Lucene doc IDs to assert the results. So at first I went for disabling merges (because they removed deleted docs and screwed up the IDs), but that didn't help entirely because for some seeds, a whole segment turned up to be deleted, and thus dropped, screwing up the IDs as well.

        So I fixed the test to add a stored field to all the docs that are deleted, and then instead of asserting that the returned docID was not marked for deletion, I assert that the returned document does not contain that field.

        I ran the test w/ -Dtests.iter=10000 (10K) and it didn't find any bad seed. Previously it hunted them pretty quickly !

        I'll commit a fix shortly to 3x and trunk.

        Show
        Shai Erera added a comment - Ok I found the problem. The test relies on Lucene doc IDs to assert the results. So at first I went for disabling merges (because they removed deleted docs and screwed up the IDs), but that didn't help entirely because for some seeds, a whole segment turned up to be deleted, and thus dropped, screwing up the IDs as well. So I fixed the test to add a stored field to all the docs that are deleted, and then instead of asserting that the returned docID was not marked for deletion, I assert that the returned document does not contain that field. I ran the test w/ -Dtests.iter=10000 (10K) and it didn't find any bad seed. Previously it hunted them pretty quickly ! I'll commit a fix shortly to 3x and trunk.
        Hide
        Shai Erera added a comment -

        Thanks Robert I'll dig. I accidentally ran w/ -Dtests.iter=100 and hit a failure w/ another seed: -Dtests.seed=7024819857743267621:1285346892471897454 too, so now there are two seeds to fix .

        Show
        Shai Erera added a comment - Thanks Robert I'll dig. I accidentally ran w/ -Dtests.iter=100 and hit a failure w/ another seed: -Dtests.seed=7024819857743267621:1285346892471897454 too, so now there are two seeds to fix .
        Hide
        Robert Muir added a comment -

        Hi Shai, I found another fail in this test:
        ant test -Dtestcase=TestScoredDocIDsUtils -Dtestmethod=testWithDeletions -Dtests.seed=-203625378244176964:-5047330594665853233

        Show
        Robert Muir added a comment - Hi Shai, I found another fail in this test: ant test -Dtestcase=TestScoredDocIDsUtils -Dtestmethod=testWithDeletions -Dtests.seed=-203625378244176964:-5047330594665853233
        Hide
        Shai Erera added a comment -

        Ok – reproduced consistently with -Dtests.seed=2719714750176374101:2498146487036328796. Issue was that test must use LogMergePolicy and not any out-of-order merges.

        Committed revision 1142385 (3x).
        Committed revision 1142386 (trunk).

        Show
        Shai Erera added a comment - Ok – reproduced consistently with -Dtests.seed=2719714750176374101:2498146487036328796. Issue was that test must use LogMergePolicy and not any out-of-order merges. Committed revision 1142385 (3x). Committed revision 1142386 (trunk).
        Hide
        Shai Erera added a comment -

        The test fails consistently with this seed -Dtests.seed=2719714750176374101:2498146487036328796 on trunk.

        I added prints to the test for when it marks a document for deletion (it adds a term) and then traversing this term's DocsEnum. I see that the lists are off by 1 (i.e instead of 0, 3, 6, 9 ... it is 0, 2, 5, 8). So I don't think the failure is related to the facets code at all.

        I've noticed the following:

        1. If I disable RandomIW, it passes
        2. If I disable RandomIW.addDocument call to maybeCommit, it passes too.
        3. Disabling maybeCommit.switchDoDocValues has no effect.

        It's the call to w.commit() which causes the IDs to offset by 1.

        Since RIW.flushAt is set to 51 (w/ the above seed), you can reduce the number of docs to index to 53 and the bug will be exposed (it didn't reproduce w/ N_DOCS=52). I'll try to isolate this bug to a standalone testcase and then run on 3x too.

        Show
        Shai Erera added a comment - The test fails consistently with this seed -Dtests.seed=2719714750176374101:2498146487036328796 on trunk. I added prints to the test for when it marks a document for deletion (it adds a term) and then traversing this term's DocsEnum. I see that the lists are off by 1 (i.e instead of 0, 3, 6, 9 ... it is 0, 2, 5, 8). So I don't think the failure is related to the facets code at all. I've noticed the following: If I disable RandomIW, it passes If I disable RandomIW.addDocument call to maybeCommit, it passes too. Disabling maybeCommit.switchDoDocValues has no effect. It's the call to w.commit() which causes the IDs to offset by 1. Since RIW.flushAt is set to 51 (w/ the above seed), you can reduce the number of docs to index to 53 and the bug will be exposed (it didn't reproduce w/ N_DOCS=52). I'll try to isolate this bug to a standalone testcase and then run on 3x too.

          People

          • Assignee:
            Shai Erera
            Reporter:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development