Hmm, I'm pretty sure I'm seeing that <listener> can take an 'enable'
attribute too. Even though that's not a <searchComponent> or a
<requestComponent>, is it?
After toggling "enable" back on forth on a listener and restarting Solr
and watching my logs closely, I am as confident as I can be that it
mysteriously is being respected on <listener>. Go figure.
Convenient for me, because I wanted to disable my expensive and
timeconsuming newSearcher/firstSearcher warming queries on a core marked
'master'.
On 2/28/2011 4:21 PM, Dyer, James wrote:
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:rochk...@jhu.edu]
Sent: Monday, February 28, 2011 3:09 PM
To: solr-user@lucene.apache.org
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:rochk...@jhu.edu]
Sent: Monday, February 28, 2011 2:03 PM
To: solr-user@lucene.apache.org
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?
