lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Solr 4.0 SnapPuller version vs. generation issue
Date Thu, 10 Jan 2013 22:41:39 GMT
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 <greggny3@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 <markrmiller@gmail.com> wrote:
> 
>> 
>> On Jan 10, 2013, at 4:11 PM, Gregg Donovan <greggny3@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


Mime
View raw message