An extension on this question: In my tests, when a slave restarts, it forgets it was sent a disable msg and carries on as specified in solrconfig.xml. This is expected, as these commands don't change any persistent cfg files.
It's looking like the ways 'round this are: 1. Extend Solr's /repliction commands to include an optional persist=true flag and either restream solrconfig.xml (yuk) or have a separate .properties file (maybe use index.properties or similar?) 2. Perform file config changes to the slave's solrconfig.xml that is completely external to Solr 3. Don't do slave-side polling - use master server-side [application] logic to force a resync to a slave periodically/as needed I'm currently implementing Option 3., as I happen to have a server-side app that can do this. Option 1. is probably a more elegant solution, and caters for environments where there is no server-side app that can (or wants to) do this. SolrCloud probably handles this in a very nice way... On Wed, Mar 31, 2010 at 3:49 PM, Peter Sturge <peter.stu...@googlemail.com>wrote: > Hi, > > Would anyone know if it is possible to persistently enable/disable > repliction remotely using Solrj (http api)? > i.e. If > http://slave_host:port/solr/repliction?command=disablepoll<http://slave_host:port/solr/replication?command=disablepoll>is > issued, and slave_host is subsequently restarted, is there a way to > ensure it remembers it isn't supposed to be replic_ting. > > Thanks, > Peter > >
