Migrating: config found, but not mapped to collection
Hi; I am migrating collections from Solr 4.3 to Solr 5.4.1 The configuration was pushed to Zookeeper, on the Zookeeper connected with Solr 5.4.1: schema.xml: solrconfig.xml: 5.4.1 I can manually create a new core, using the Solr Admin UI, as long as I use the name "otac_en" for parameter "collection". Solr default for collection.configName is the same name given for the collection. However, I have to migrate a number of collections that have a variety of names, some name created automatically by an application (example: a-0c512bac-abc9-48e9-8f66-96432b724263_shard1_replica1) "Normally", if the collections have the same name as the configuration, I can either point the new Solr 5.4.1 home to the old Solr 4.3 home, or copy the collection folder from the old /solr folder to the new /solr. But here, for every collection that has a different name than the config, I get: SolrCore Initialization Failures a-0c512bac-abc9-48e9-8f66-96432b724263_shard1_replica1: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Could not find configName for collection a-0c512bac-abc9-48e9-8f66-96432b724263 found:[otif_und, otif_de, otif_fr, otif_it, otif_es, otif_nl, otif_noText, otif_ja, otac_en, otif_en, otif_pt, otif_ru] Where can I specify collection.configName when SolrCore Initialization runs ? Thanks; -- View this message in context: http://lucene.472066.n3.nabble.com/Migrating-config-found-but-not-mapped-to-collection-tp4295375.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Migrating: config found, but not mapped to collection
Hi JohnB; We have a script that calls the ZK CLI with this command: zk.bat -cmd upconfig -zkhost %SOLR_ZK_ENSEMBLE% -confdir %INSTALL_DIR%\etc\solr\otac\default-en\conf -confname otac_en The scrtipt does the job: the config is visible at /ot/solr/configs/otac_en You can see in Solr's error message that the config does exist: otac_en found:[otif_und, otif_de, otif_fr, otif_it, otif_es, otif_nl, otif_noText, otif_ja, otac_en, otif_en, otif_pt, otif_ru] In ZK, clusterstate.js contains information about the collection, but /ot/solr/collections is empty. Thanks; -- View this message in context: http://lucene.472066.n3.nabble.com/Migrating-config-found-but-not-mapped-to-collection-tp4295375p4295384.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Migrating: config found, but not mapped to collection
Hi again; To answer your questions: 1. I use a ZK browser, so I can see what happens in ZK. https://github.com/DeemOpen/zkui 2. Solr 4.3 is on it's own ZK, on one server. Solr 5.4 is on another ZK, on a different server. No mixing whatsoever. 3. Take to mean "ZK root", so, yes /ot is at the root Meanwhile, I have made some "progress", if that's what I could call it. By deleting form ZK all the irrelevant configurations, and leaving only "otac_en", I was able to migrate one collection. Fortunately, for this specific project, only "otac_en" is relevant, so we could live with the deletion of the other configs. However, we can't expect ZK to only ever hold just one config for Solr. -- View this message in context: http://lucene.472066.n3.nabble.com/Migrating-config-found-but-not-mapped-to-collection-tp4295375p4295391.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Migrating: config found, but not mapped to collection
Sorry for the confusion... I forget that not everyone sees what I see ;) The other configs that I mention are from another application that uses Solr and Zookeeper. In theory, both apps should be able to share resources like Solr and ZK, but I need to double-check on the necessity to have both app's Solr configurations on the same ZK... Thank you for your help! -- View this message in context: http://lucene.472066.n3.nabble.com/Migrating-config-found-but-not-mapped-to-collection-tp4295375p4295394.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Migrating: config found, but not mapped to collection
"If you want the new apps to use the latest Solr, then I would assume you want them on the new ZKworry about the config." - Don't worry about that. That was the easy part. We install and configure these apps often enough during a development phase! I double-checked the requirements, and Solr configurations of the other app are not needed on the same ZK. So, for my part, my problem is solved (for now): one config, to avoid confusion, then migration goes smoothly. I hope you have as much fun with you migration(s)... ;) Thanks again. -- View this message in context: http://lucene.472066.n3.nabble.com/Migrating-config-found-but-not-mapped-to-collection-tp4295375p4295400.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Russian stopwords
I'm encountering the same issue, but, my Russian stopwords.txt IS encoded in UTF-8. I verified the encoding using EmEditor (I've used it for years, and I use it for the existing English, French, Spanish, Portuguese and German Solr configurations, without issues). Just to make extra sure, I downloaded Edit Plus, as mentioned in this thread, and verified the encoding again: UTF-8 I realize this will pass for a stupid question, but... Could there be any issue other than encoding ? Thanks; -- View this message in context: http://lucene.472066.n3.nabble.com/Russian-stopwords-tp491490p4065440.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Russian stopwords
Just so everyone knows : It turns out my stopwords.txt was OK after all. It functions correctly on a Linux (ubuntu), and, strangely, on a colleague's Windows 7. My computer is also Windows 7. The only difference between the 2 Windows is the language of the interface (French for mine, English for my colleague). Strange... Very very strange. I hope someone from Microsoft reads this someday. -- View this message in context: http://lucene.472066.n3.nabble.com/Russian-stopwords-tp491490p4065910.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Russian stopwords
A colleague stumbled upon this : http://stackoverflow.com/questions/361975/setting-the-default-java-character-encoding The second answer, environment variable JAVA_TOOL_OPTIONS did the job. JAVA_TOOL_OPTIONS : -Dfile.encoding=UTF8 Happy stop-wording ! -- View this message in context: http://lucene.472066.n3.nabble.com/Russian-stopwords-tp491490p4065976.html Sent from the Solr - User mailing list archive at Nabble.com.
