Thanks for wrapping that up..... Erick
On Mon, Aug 6, 2012 at 2:52 PM, csscouter <tim.hi...@verizon.net> wrote: > 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 <name> 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: > > <lst name="slave"> > <str name="enable">true</str> > <str name="masterUrl">http://<host>:<port>/<solr home location, in my case > 'apache-solr-3.3.0'>/replication</str> > <str name="pollInterval">00:00:60</str> > </lst> > > The key here is the line <str name="enable">true</str>. 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: > > <str name="enable">true</str> > > as: > > <str name="enable">${org.apache.solr.handler.enable.slave:false}</str> > > 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: > > <str name="enable">true</str> > > 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-tp3999272p3999447.html > Sent from the Solr - User mailing list archive at Nabble.com.
