Hmm…I don't recall that change. We use the force, so SolrCloud certainly does not depend on it.
It seems like it might be a mistake - some dev code that got caught up with the commit? I'm a little surprised it wouldn't trip any tests…I still have to read your first email closely though. - Mark On Jan 10, 2013, at 4:49 PM, Gregg Donovan <gregg...@gmail.com> wrote: > Thanks, Mark. > > The relevant commit on the solrcloud branch appears to be 1231134 and is > focused on the recovery aspect of SolrCloud: > > http://svn.apache.org/viewvc?diff_format=h&view=revision&revision=1231134 > http://svn.apache.org/viewvc/lucene/dev/branches/solrcloud/solr/core/src/java/org/apache/solr/handler/SnapPuller.java?diff_format=h&r1=1231133&r2=1231134&; > > I tried changed the check on our 4.0 test cluster to: > > boolean isFullCopyNeeded = > IndexDeletionPolicyWrapper.getCommitTimestamp(commit) >= latestVersion > || commit.getGeneration() >= latestGeneration || forceReplication; > > and that fixed our post-reindexing HTTP replication issues. But I'm not > sure if that check works for all of the cases that SnapPuller is designed > for. > > --Gregg > > On Thu, Jan 10, 2013 at 4:28 PM, Mark Miller <markrmil...@gmail.com> wrote: > >> >> On Jan 10, 2013, at 4:11 PM, Gregg Donovan <gregg...@gmail.com> wrote: >> >>> If the commitTimeMSec based check in Solr 4.0 is needed for SolrCloud, >> >> It's not. SolrCloud just uses the force option. I think this other change >> was made because Lucene stopped using both generation and version. I can >> try and look closer later - can't remember who made the change in Solr. >> >> - Mark
