[
https://issues.apache.org/jira/browse/LUCENE-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575716#comment-14575716
]
Robert Muir commented on LUCENE-6529:
-------------------------------------
In the case of all 3 provided seeds we have:
{noformat}
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene50):
{foo=PostingsFormat(name=MockRandom)}
{noformat}
If i disable the ord-sharing optimization in DocTermOrds, all 3 seeds pass. So
I think there is a bug in e.g. FixedGap/BlockTerms dictionary or something like
that. Maybe BasePostingsFormatTestCase does not adequately exercise methods
like size()/ord()/seek(ord). It should be failing!
> NumericFields + SlowCompositeReaderWrapper + UninvertedReader +
> -Dtests.codec=random can results in incorrect SortedSetDocValues
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-6529
> URL: https://issues.apache.org/jira/browse/LUCENE-6529
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Hoss Man
> Attachments: LUCENE-6529.patch
>
>
> Digging into SOLR-7631 and SOLR-7605 I became fairly confident that the only
> explanation of the behavior i was seeing was some sort of bug in either the
> randomized codec/postings-format or the UninvertedReader, that was only
> evident when two were combined and used on a multivalued Numeric Field using
> precision steps. But since i couldn't find any -Dtests.codec or
> -Dtests.postings.format options that would cause the bug 100% regardless of
> seed, I switched tactices and focused on reproducing the problem using
> UninvertedReader directly and checking the SortedSetDocValues.getValueCount().
> I now have a test that fails frequently (and consistently for any seed i
> find), but only with -Dtests.codec=random -- override it with
> -Dtests.codec=default and everything works fine (based on the exhaustive
> testing I did in the linked issues, i suspect every named codec works fine -
> but i didn't re-do that testing here)
> The failures only seem to happen when checking the
> SortedSetDocValues.getValueCount() of a SlowCompositeReaderWrapper around the
> UninvertedReader -- which suggests the root bug may actually be in
> SlowCompositeReaderWrapper? (but still has some dependency on the random
> codec)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
