[
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: [email protected]
For additional commands, e-mail: [email protected]
