I think you must be confused? Solr 3.6 and before worked the same way - getIndexDir never read the props file - getNewIndexDir always did. This was added when replication was added as far as I remember.
The idea is that you use that when constructing new searcher/writers but you shouldn't need to in other cases - i think a comment exists somewhere to that affect. In any case, none of the replication handler changes are SolrCloud specific - they are all replication handler specific. We don't ask anything special of the replication handler in SolrCloud mode, other than adding a force option that guarantees a replication. - Mark On Feb 6, 2013, at 4:23 PM, Gregg Donovan <gregg...@gmail.com> wrote: > In the process of upgrading from 3.6 to 4.1, we've noticed that much of the > code we had that relied on the 3.6 behavior of SolrCore#getIndexDir() is > not working the same way. > > In 3.6, SolrCore#getIndexDir() would get us the index directory read from > index.properties, if it existed, otherwise it would return dataDir + > "index/". As of svn 1420992 [1], SolrCore#getIndexDir() just > returns dataDir + "index/" and does not take index.properties into account. > > This has me wondering what the intended state of support for > index.properties is in 4.1. After reading the code for some of the relevant > components -- Core admin, HTTP Replication, etc. -- I'm somewhat confused. > > --In CoreAdminHandler#handleUnloadAction(SolrQueryRequest, > SolrQueryResponse) if the deleteIndex flag is set to true, it calls > core.getDirectoryFactory().remove(core.getIndexDir()). If a value other > than index/ is set in index.properties, won't this delete the wrong > directory? > > --In CoreAdminHandler#getIndexSize(SolrCore), the existence of > SolrCore#getIndexDir() is checked before SolrCore#getNewIndexDir(). If a > value other than index/ is set in index.properties, won't this return the > size of the wrong directory? > > Seeing these two examples, I wondered if index.properties and the use of > directories other than <dataDir>/index/ was deprecated, but I see that > SnapPuller will create a new directory within <dataDir> and update > index.properties to point to it in cases where isFullCopyNeeded=true. > > Our current Solr 3.6 reindexing scheme works by modifying index.properties > to point to a new directory and then doing a core reload. I'm wondering if > this method is intended to be deprecated at this point, or if the SolrCloud > scenarios are just getting more attention and some bugs have slipped into > the older code paths. I can certainly appreciate that it's tough to make > the changes needed for SolrCloud while maintaining perfect compatibility in > pre-Cloud code paths. Would restoring the previous contact of > SolrCore#getIndexDir() break anything in SolrCloud? > > Thanks! > > --Gregg > > > Gregg Donovan > Senior Software Engineer, Etsy.com > gr...@etsy.com > > [1] > http://svn.apache.org/viewvc?diff_format=h&view=revision&revision=1420992
