[ https://issues.apache.org/jira/browse/LUCENE-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated LUCENE-7301: ----------------------------- Attachment: LUCENE-7301.patch I distilled testSomeSortOfWeirdFlushIssue down to the minimal set of operations that demonstrate the bug with only 2 docs, and cleaned up the docIds and values used so it's a bit easier to see at a glance what changed/expected for each doc... {code} writer.updateDocument (new Term("id","doc-1"), doc(1, 1000000000L )); writer.updateNumericDocValue(new Term("id","doc-1"), "val", 1000001111L ); writer.updateDocument (new Term("id","doc-2"), doc(2, 2000000000L )); writer.updateDocument (new Term("id","doc-2"), doc(2, 2222222222L )); writer.updateNumericDocValue(new Term("id","doc-1"), "val", 1111111111L ); writer.commit(); {code} I also added a much beefier "testBiasedMixOfRandomUpdates" which mixes a random assortment of addDocument, updateDocument, and updateNumericDocValue calls, using a randomly pre-assigned bias (so in one run, addDocument may happen more often then the other ops, but in the next run updateNumericDocValue may dominate the test) testBiasedMixOfRandomUpdates falls a lot of the time, but not all of the time -- seeds that fail seem to fail reliably, seeds that pass also seem to pass reliably. > updateNumericDocValue mixed with updateDocument can cause data loss in some > randomized testing > ---------------------------------------------------------------------------------------------- > > Key: LUCENE-7301 > URL: https://issues.apache.org/jira/browse/LUCENE-7301 > Project: Lucene - Core > Issue Type: Bug > Reporter: Hoss Man > Attachments: LUCENE-7301.patch, LUCENE-7301.patch > > > SOLR-5944 has been held up by a while due to some extremely rare randomized > test failures. > Ishan and I have been working on whitling those Solr test failures down, > trying to create more isolated reproducable test failures, and i *think* i've > tracked it down to a bug in IndexWriter when the client calls to > updateDocument intermixed with calls to updateNumericDocValue *AND* > IndexWriterConfig.setMaxBufferedDocs is very low (i suspect "how low" depends > on the number of quantity/types of updates -- but *just* got something that > reproduced, and haven't tried reproducing with higher values of > maxBufferedDocs and larger sequences of updateDocument / > updateNumericDocValue calls. -- 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