I've fixed this - thanks Gregg. https://issues.apache.org/jira/browse/SOLR-4303
- Mark On Jan 10, 2013, at 5:41 PM, Mark Miller <markrmil...@gmail.com> wrote: > 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 >
