Thanks Yonik, I really appreciate the explanation. It sounds like the best solution for me to solve this is to add the additional sort parameter. That being said is there a significant memory increase to do this when sorting by score? I don't see how with SolrCloud I can avoid doing this, and how others wouldn't need to do the same thing.
On Tue, Mar 20, 2012 at 1:38 PM, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Tue, Mar 20, 2012 at 1:07 PM, Jamie Johnson <jej2...@gmail.com> wrote: >> I believe we're using replication to only duplicate the index >> (standard SolrCloud nothing special on our end) so I don't see why the >> docids wouldn't be the same....am I missing something that is >> happening there that I am unaware of? > > Each document is pushed to the replicas (i.e. standard whole-index > "replication" is only used in recovery scenarios). If you're using > multiple threads to index, then docA can be indexed before docB on one > replica and vice-versa on a different replica (or on the leader). > Although even if this were not the case, I don't believe Lucene is > deterministic in this respect anyway (i.e. indexing identically on two > different boxes is not guaranteed to result in the exact same internal > document order). > > -Yonik > lucenerevolution.com - Lucene/Solr Open Source Search Conference. > Boston May 7-10
