[
https://issues.apache.org/jira/browse/LUCENE-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964190#comment-13964190
]
Michael McCandless commented on LUCENE-5587:
--------------------------------------------
OK two things:
* With this seed, the first index flushes only a single segment, and so
forceMerge does nothing. This is unusual (often, RandomIndexWriter will do a
random commit with atLeast(500) docs).
* When flushing, we write according to HashMap iterator order (undefined),
while for merging we write according to FieldInfos iteration order, and so the
.dat file holding the doc values has the fields in a different order, which
results in a different checksum. Furthermore, the checksums have a different
number of digits, and this explains why it's only SimpleText that's failing
here (the other formats do a .writeLong for the checksum so the byte length
will be the same).
We could ... disable this checking for SimpleText (not ideal), or, we could fix
SimpleText to 0 or space pad its checksum line (I prefer this option).
> TestSimpleTextDocValuesFormat.testMergeStability -seed 161C8BDA82B2190F
> -----------------------------------------------------------------------
>
> Key: LUCENE-5587
> URL: https://issues.apache.org/jira/browse/LUCENE-5587
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.8, 5.0
>
>
> Fails with this:
> {noformat}
> java.lang.AssertionError: expected:<{null=91, dat=39791, gen=36, pst=24,
> inf=697, fld=14434}> but was:<{null=91, dat=39792, gen=36, pst=24, inf=697,
> fld=14434}>
> at
> __randomizedtesting.SeedInfo.seed([161C8BDA82B2190F:6250CDF58F581BB9]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:147)
> at
> org.apache.lucene.index.BaseIndexFileFormatTestCase.testMergeStability(BaseIndexFileFormatTestCase.java:111)
> at
> org.apache.lucene.index.BaseDocValuesFormatTestCase.testMergeStability(BaseDocValuesFormatTestCase.java:70)
> {noformat}
> I'm digging ... it's because we add the DV fields in a different order for
> the 2nd index ... not sure why the other DVFs aren't affected (or maybe they
> are).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
