[
https://issues.apache.org/jira/browse/SOLR-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16523391#comment-16523391
]
Steve Rowe commented on SOLR-11216:
-----------------------------------
Another reproducing seed from
[https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/56/]:
{noformat}
Checking out Revision 095f9eb90db92649a0805e83ff5a0ec93763a31f
(refs/remotes/origin/master)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestStressCloudBlindAtomicUpdates -Dtests.method=test_dv_idx
-Dtests.seed=3006617022AC9671 -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.badapples=true -Dtests.locale=de -Dtests.timezone=Etc/GMT+5
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 14.5s J1 | TestStressCloudBlindAtomicUpdates.test_dv_idx <<<
[junit4] > Throwable #1: java.lang.AssertionError: Some docs had errors
-- check logs expected:<0> but was:<4>
[junit4] > at
__randomizedtesting.SeedInfo.seed([3006617022AC9671:A57A14B8FE703B90]:0)
[junit4] > at
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:342)
[junit4] > at
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_idx(TestStressCloudBlindAtomicUpdates.java:231)
[junit4] > at java.lang.Thread.run(Thread.java:748)
[junit4] 2> 1499188 INFO
(TEST-TestStressCloudBlindAtomicUpdates.test_dv_stored-seed#[3006617022AC9671])
[ ] o.a.s.SolrTestCaseJ4 ###Starting test_dv_stored
[...]
{noformat}
> Race condition in peerSync
> --------------------------
>
> Key: SOLR-11216
> URL: https://issues.apache.org/jira/browse/SOLR-11216
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.4
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-11216.patch, SOLR-11216.patch, SOLR-11216.patch,
> SOLR-11216.patch, SOLR-11216.patch, SOLR-11216.patch, SOLR-11216.patch
>
>
> When digging into SOLR-10126. I found a case that can make peerSync fail.
> * leader and replica receive update from 1 to 4
> * replica stop
> * replica miss updates 5, 6
> * replica start recovery
> ## replica buffer updates 7, 8
> ## replica request versions from leader,
> ## in the same time leader receive update 9, so it will return updates from 1
> to 9 (for request versions) when replica get recent versions ( so it will be
> 1,2,3,4,5,6,7,8,9 )
> ## replica do peersync and request updates 5, 6, 9 from leader
> ## replica apply updates 5, 6, 9. Its index does not have update 7, 8 and
> maxVersionSpecified for fingerprint is 9, therefore compare fingerprint will
> fail
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
