Re: Solr 4.0 SnapPuller version vs. generation issue

2013-01-14 Thread Mark Miller 
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=hview=revisionrevision=1231134
 http://svn.apache.org/viewvc/lucene/dev/branches/solrcloud/solr/core/src/java/org/apache/solr/handler/SnapPuller.java?diff_format=hr1=1231133r2=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

Re: Solr 4.0 SnapPuller version vs. generation issue

2013-01-10 Thread Mark Miller 

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

Re: Solr 4.0 SnapPuller version vs. generation issue

2013-01-10 Thread Gregg Donovan 
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=hview=revisionrevision=1231134
http://svn.apache.org/viewvc/lucene/dev/branches/solrcloud/solr/core/src/java/org/apache/solr/handler/SnapPuller.java?diff_format=hr1=1231133r2=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

Re: Solr 4.0 SnapPuller version vs. generation issue

2013-01-10 Thread Mark Miller 
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=hview=revisionrevision=1231134
 http://svn.apache.org/viewvc/lucene/dev/branches/solrcloud/solr/core/src/java/org/apache/solr/handler/SnapPuller.java?diff_format=hr1=1231133r2=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