Re: disable replication in a persistent way

[Mark Miller <ma...@gmail.com>]

Yeah - as I just said in another email, I think this is fairly low hanging fruit - only reason I have not gotten after it (besides infinite time) is that SolrCloud indexing side will likely move away from replication. This is still a nice feature to have IMO though.

- Mark

On Feb 24, 2011, at 9:51 AM, Jan Høydahl wrote:

> I think all of this should be adapted for SolrCloud.
> ZK should be the one knowing which is master and slave. ZK should know whether replication on a slave is disabled or not. To disable replication it should be enough to set a new value in ZK, and the node will be notified and change behaviour at next poll. Thus, in a ZK environment we'll not need the replicationHandler section of solrconfig.xml at all, as it should be stored in distinct ZK nodes, not? We somehow have to refactor this to work seamlessly with and without ZK.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> On 24. feb. 2011, at 05.10, Otis Gospodnetic wrote:
> 
>> Hi,
>> 
>> 
>> ----- Original Message ----
>>> From: Ahmet Arslan <io...@yahoo.com>
>>> Subject: disable replication in a persistent way
>>> 
>>> Hello,
>>> 
>>> solr/replication?command=disablepoll disables replication on  slave(s). However 
>>> it is not persistent. After solr/tomcat restart, slave(s) will  continue 
>>> polling. 
>>> 
>>> 
>>> Is there a built-in way to disable replication on  slave side in a persistent 
>>> manner?
>> 
>> Not that I know of.
>> 
>> Hoss or somebody else will correct me if I'm wrong :)
>> 
>>> Currently I am using system property  substitution along with 
>>> solrcore.properties file to simulate  this.
>>> 
>>> <lst name="slave">
>>>   <str  name="enable">${enable.slave:false}</str> 
>>> 
>>> #solrcore.properties  in slave
>>> enable.master=true
>>> 
>>> And modify solrcore.properties with a  custom solr request handler after the 
>>> disablepoll command, to make it  persistent. It seems that there is no existing 
>>> mechanism to write  solrconfig.properties file, am I  correct?
>> 
>> What about modifying the existing classes (the one/ones that handle the 
>> disablepoll command) to take another param: persist=true|false ?
>> Would that be better than a custom Solr request handler that requires a separate 
>> call?
>> 
>> Otis
>> ----
>> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
>> Lucene ecosystem search :: http://search-lucene.com/
>> 
> 

- Mark Miller
lucidimagination.com