On 10/4/2013 7:21 PM, Trey Grainger wrote: > There are two use-cases that appear broken with the new core > auto-discovery mechanism: > > *1) The Core Admin Handler's CREATE command no longer works to create > brand new cores* > (unless you have logged on the box and created the core's directory > structure manually, which largely defeats the purpose of the "CREATE" > command). With the old Solr.xml format, we could spin up as many cores > as we wanted to dynamically with the following command: > http://localhost:8983/solr/admin/cores?action=CREATE&name=newCore1&instanceDir=collection1&dataDir=newCore1/data > ... > http://localhost:8983/solr/admin/cores?action=CREATE&name=newCoreN&instanceDir=collection1&dataDir=newCoreN/data > > In the new core discovery mode, this exception is now thrown: > Error CREATEing SolrCore 'newCore1': Could not create a new core in > solr/collection1/as another core is already defined there
The CREATE action has *always* required that you have your configuration on the disk before you call it. You are sharing the instanceDir, which is the only reason you can skip that step. If you want completely dynamic creation, use SolrCloud, which keeps the config in zookeeper and requires ZERO config information to exist on the disk. > *2) Having a shared configuration directory (instanceDir) across many > cores no longer works*. > Every core has to have it's own conf/ directory, and this doesn't seem > to be overridable any longer. Previously, it was possible to have many > cores share the same instanceDir (and just override their dataDir for > obvious reasons). Now, it is necessary to copy and paste identical > config files for each Solr core. >From what I understand talking to the people that worked on this, the lack of a shared instanceDir was completely deliberate. It's the only way that core discovery can work in any kind of predictable and sane manner. The entire point of it is that every core is self-contained and solr.xml isn't used to tell Solr about them. I personally have never tried to share the instanceDir. I do have shared configs, though - my corename/conf directories have symlinks to a shared config directory. I also don't dynamically create cores - I have seven shards, each of which has a live core and a build core. There are two other cores that serve as frontends, with the shards parameter in the request handlers. > I don't know if there's already a current roadmap for fixing this. I > saw https://issues.apache.org/jira/browse/SOLR-4478, which suggested > replacing instanceDir with the ability to specify a named configSet. > This solves problem 2, but not problem1 (since you still can't have > multiple core.properties files in the same folder). Based on Erick's > comments in the JIRA ticket, it also sounds like this ticket is also > dead at the moment. > > There is definitely a need to have a shared config directory - whether > that is through a configSet or an explicit indexDir doesn't matter to > me. There's also a need to be able to dynamically create Solr cores > from external systems. I currently can't upgrade to core auto discovery > because it doesn't allow dynamic core creation. Does anyone have some > thoughts on how to best get these features working again under core > autodiscovery? Adding instanceDir to core.properties seems like an easy > solution, but there must be a desire not to do that or it would probably > have already been done. Thankfully, you do not need to upgrade to core discovery anytime soon. All future 4.x versions will support the old format, and any problems with that will be considered bugs. It will be mandatory in Solr 5.0, which currently doesn't have any kind of release roadmap or timeframe. I suspect that what we currently call "SolrCloud" will also be mandatory in 5.0, and that gives you shared configs with zookeeper. Requiring zookeeper allows completely dynamic core/collection creation, because the only thing that will be on the disk is the index and transaction log data. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
