Just did a quick search for ' enable=" ' in the 1.4.1 source. Looks like from the example solrconfig.xml, both <searchComponent> and <requestHandler> tags can take the "enable" attribute. Its only shown with the "ClusteringComponent" so I'm not sure if just any SC or RH will honor it. Also see the unit test "TestPluginEnable.java", which seems to show that the StandardRequestHandler will honor it.
James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -----Original Message----- From: Jonathan Rochkind [mailto:[email protected]] Sent: Monday, February 28, 2011 3:09 PM To: [email protected] Subject: Re: setting different solrconfig.xml for a core And in other news of other possibilities. If I DID want to use the same solrconfig.xml for both master and slave, but disable the newsearcher/firstsearcher queries on master, it _looks_ like I can use the techique here: http://wiki.apache.org/solr/SolrReplication#enable.2BAC8-disable_master.2BAC8-slave_in_a_node Applied to newsearcher/firstsearcher too: <listener event="firstSearcher" class="solr.QuerySenderListener" enable="${enable.slave:false}"> Now that listener will only be turned on if enable.slave is set to true. Might make more sense to use a different property value there, like "enable.searcher" or something. I'm not entirely sure in what places the "enable" attribute is recognized and in what places it isn't, but it LOOKS like it's recognized on the <listener> tag. I think. On 2/28/2011 3:52 PM, Jonathan Rochkind wrote: > Aha, wait, I think I've made it work, as simple as this in the solr.xml > core config, to make a core use a solrconfig.xml file with a different name: > > ...<core name="master_prod" instanceDir="master_prod" > config="master-solrconfig.xml"> ... > > Not sure why that didn't work the first half a dozen times I tried. May > have had a syntax error in my master-solrconfig.xml file, even though > the Solr log files didn't report any, maybe when there's a syntax error > Solr just silently gives up on the config file and presents an empty > index, I dunno. > > On 2/28/2011 3:46 PM, Jonathan Rochkind wrote: >> Yeah, I'm actually _not_ trying to get replication to copy over the >> config files. Instead, I'm assuming the config files are all there, and >> I'm actually trying to get one of the cores to _use_ a file that >> actually on disk in that core is called, eg, "solrconfig_slave.xml". >> >> This wiki page: http://wiki.apache.org/solr/CoreAdmin >> >> suggests I _ought_ to be able to do that, to tell a particular core to >> use a config file of any name I want. But I'm having trouble getting it >> to work. But that could be my own local mistake of some kind too. Just >> makes it harder to figure out when I'm not even exactly sure how you're >> _supposed_ to be able to do that -- CoreAdmin wiki page implies at least >> two different ways you should be able to do it, but doesn't include an >> actual example so I'm not sure if I'm understanding what it's implying >> correctly -- or if the actual 1.4.1 behavior matches what's in that wiki >> page anyway. >> >> On 2/28/2011 3:14 PM, Dyer, James wrote: >>> Jonathan, >>> >>> When I was first setting up replication a couple weeks ago, I had this >>> working, as described here: >>> http://wiki.apache.org/solr/SolrReplication#Replicating_solrconfig.xml >>> >>> I created the slave's "solrconfig.xml" and saved it on the master in the >>> "conf" dir as "solrconfig_slave.xml", then began the "confFiles" parameter >>> on the master with "solrconfig_slave.xml:solrconfig.xml,schema.xml,etc". >>> And it was working (v1.4.1). I'm not sure why you haven't had good luck >>> with this but you can at least know it is possible to get it to work. >>> >>> I think to get the slave up and running for the first time I saved the >>> slave's version on the slave as "solrconfig.xml". It then would copy over >>> any changed versions of "solrconfig_slave.xml" from the master to the >>> slave, saving them on the slave as "solrconfig.xml". But I primed it by >>> giving it its config file in-sync to start with. >>> >>> I ended up going the same-config-file-everywhere route though because we're >>> using our master to handle requests when its not indexing (one less server >>> to buy)... >>> >>> James Dyer >>> E-Commerce Systems >>> Ingram Content Group >>> (615) 213-4311 >>> >>> -----Original Message----- >>> From: Jonathan Rochkind [mailto:[email protected]] >>> Sent: Monday, February 28, 2011 2:03 PM >>> To: [email protected] >>> Subject: Re: setting different solrconfig.xml for a core >>> >>> Okay, I did manage to find a clue from the log that it's not working, >>> when it's not working: >>> >>> INFO: Jk running ID=0 time=0/66 config=null >>> >>> config=null, that's not right. When I try to over-ride the config file >>> name in solr.xml core config, I can't seem to put a name in there that >>> works to find a file that does actually exist. Unless I put the name >>> "solrconfig.xml" in there, then it works fine, heh. >>> >>> >>> >>> On 2/28/2011 3:00 PM, Jonathan Rochkind wrote: >>>> On 2/28/2011 1:09 PM, Ahmet Arslan wrote: >>>>>> (The reason I want to do this is so I can have master and >>>>>> slave in replication have the exact same repo checkout for >>>>>> their conf directory, but have the master using a different >>>>>> solrconfig.xml, one set up to be master.) >>>>> How about using same solrconfig.xml for master too? As described here: >>>>> >>>>> http://wiki.apache.org/solr/SolrReplication#enable.2BAC8-disable_master.2BAC8-slave_in_a_node >>>>> >>>> That isn't great, becuase there are more differences in optimal >>>> solrconfig.xml between master and slave than just the replication >>>> handler difference, which that URL covers. >>>> >>>> A master (which won't be queried against) doesn't need spellcheck >>>> running after commits, but the slave does. A master doesn't need slow >>>> newsearcher/firstsearcher query warm-ups, but the slave does. The master >>>> may be better with different (lower) cache settings, since it won't be >>>> used to service live queries. >>>> >>>> The documentation clearly suggests it _ought_ to be possible to tell a >>>> core the name of it's config file (default solrconfig.xml) to be >>>> something other than solrconfig.xml -- but I havent' been able to make >>>> it work, and find the lack of any errors in the log file when it's not >>>> working to be frustrating. >>>> >>>> Has anyone actually done this? Can anyone confirm that it's even >>>> possible, and the documentation isn't just taking me for a ride? >>>> >>>>
