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 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 t
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.
- Mar
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/so
On Jan 10, 2013, at 4:11 PM, Gregg Donovan 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 la
We are in the midst of upgrading from Solr 3.6 to Solr 4.0 and have
encountered an issue with the method the SnapPuller now uses to determine
if a new directory is needed when fetching files to a slave from master.
With Solr 3.6, our reindexing process was:
On master:
1. Reindex in a separate pro
