[ https://issues.apache.org/jira/browse/SOLR-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514244#comment-16514244 ]
Yonik Seeley commented on SOLR-11216: ------------------------------------- {quote} SolrQueryRequest req = new LocalSolrQueryRequest(core, new ModifiableSolrParams()); request is not safely closed, is this intentional? won't this break the reference count mechanism? {quote} Yeah, it does look like it should be closed. A SolrQueryRequest grabs a searcher reference on-demand, so that may be why it isn't causing an issue with any tests (the commit command doesn't grab a searcher reference with the provided request). It should be fixed anyway though. > Make PeerSync more robust > ------------------------- > > Key: SOLR-11216 > URL: https://issues.apache.org/jira/browse/SOLR-11216 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Cao Manh Dat > Priority: Major > Attachments: SOLR-11216.patch, SOLR-11216.patch, SOLR-11216.patch > > > First of all, I will change the issue's title with a better name when I have. > 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 > My idea here is why replica request update 9 (step 6) while it knows that > updates with lower version ( update 7, 8 ) are on its buffering tlog. Should > we request only updates that lower than the lowest update in its buffering > tlog ( < 7 )? > Someone my ask that what if replica won't receive update 9. In that case, > leader will put the replica into LIR state, so replica will run recovery > process again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org