Erick, Thank you for the courtesy of your reply.
I was able to figure out the problem, and for the benefit of the list, I list the analysis. Judging by the caliber of those on this list, this is likely too basic for the interests of most, but newbies (among whom I still classify myself) might benefit. Here's what occurred: Recall that the version I'm using is 3.3. I don't know if these comments can extend to versions other than 3.3, but I suspect so. I noted in my initial "plea": /I seem to recall that the slaves USED TO > say "Solr Replication Slave"./ It turns out that is indeed the case, and > that was a clue that they weren't being recognized as slave servers. The > file solrconfig.xml contains the configuration setup for replication, > under the entry "<requestHandler name="/replication ... > </requestHandler>. A slave "knows" it's a slave by the following entry: true http://://replication 00:00:60 The key here is the line true. There is at least one "fancy" way to define "trueness" or "falseness" - by defining the value as a parameter, and passing the resolution to the parameter in to solr when it starts. The reason for using this technique is to allow a single solrconfig.xml file to be deployed to all servers running solr, and then configuring those servers as slaves or the master at the time the servers start. (The information on doing this is in the solr wiki documentation for Replication at http://wiki.apache.org/solr/SolrReplication#enable.2BAC8-disable_master.2BAC8-slave_in_a_node, incidentally). In my case, I'm running solr under WebLogic 10.3.2 application server. I had defined the line: true as: ${org.apache.solr.handler.enable.slave:false} in my solrconfig.xml, and had been starting the WebLogic managed servers with the parameter "-Dorg.apache.solr.handler.enable.master=false". Note that this parameter deals with the *master* and not the slave. This was working in my existing environment, and despite the fact that no "-Dorg.apache.solr.handler.enable.slave=true" parameter was being passed in from WebLogic, the slaves were able to recognize themselves as slaves. In the new WebLogic environment, this was no longer the case. I don't know why at this point. To solve the problem for the short term, I created a separate file for the slave servers that bypassed the whole parameter-resolution mechanism by defining that line under the slave configuration in its solrconfig.xml as: true That, of course, now leaves me with 2 solrconfig.xml files - one for the master server, and one for the slave servers. My bottom line is that at least it's now working, people are not being impacted, and I can troubleshoot the underlying issue at a more leisurely pace. Hope this helps someone, somewhere. Erick, thanks for taking an interest. Tim Hibbs -- View this message in context: http://lucene.472066.n3.nabble.com/Stopping-replication-tp3999272p3999445.html Sent from the Solr - User mailing list archive at Nabble.com.
