[ 
https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601775#action_12601775
 ] 

Hoss Man commented on SOLR-561:
-------------------------------

bq. If scheduling is indeed important we will take it up.
bq. Meanwhile we need to ensure that the solution is usable and bug free.

agreed ... the challenge here is (efficient) pure java equivalents of 
snapshooter/snappuller/snapinstaller ... the scheduling mechanism is largely 
orthogonal, particularly since Paul is using a "ReplicationHandler" as the main 
API.  it could easily be dealt with later (or in parallel if anyone wants to 
take on the task)

i don't think the ReplicationHandler should know *anything* about scheduling or 
recurance. A generic Scheduling system could be hooked into SolrCore that can 
hit arbitrary RequestHandlers according to whatever configuration it has 
(similar to the QuerySendEventListener) which would handle this case, as well 
as other interesting use cases (ie: rebuild a spelling dictionary using an 
external datasource every hour, even if the index hasn't changed)

the scheduling aspect can easily be dealt with later (or in parallel if anyone 
wants to take on the task)


> Solr replication by Solr (for windows also)
> -------------------------------------------
>
>                 Key: SOLR-561
>                 URL: https://issues.apache.org/jira/browse/SOLR-561
>             Project: Solr
>          Issue Type: New Feature
>          Components: replication
>    Affects Versions: 1.3
>         Environment: All
>            Reporter: Noble Paul
>         Attachments: SOLR-561.patch, SOLR-561.patch
>
>
> The current replication strategy in solr involves shell scripts . The 
> following are the drawbacks with the approach
> *  It does not work with windows
> * Replication works as a separate piece not integrated with solr.
> * Cannot control replication from solr admin/JMX
> * Each operation requires manual telnet to the host
> Doing the replication in java has the following advantages
> * Platform independence
> * Manual steps can be completely eliminated. Everything can be driven from 
> solrconfig.xml .
> ** Adding the url of the master in the slaves should be good enough to enable 
> replication. Other things like frequency of
> snapshoot/snappull can also be configured . All other information can be 
> automatically obtained.
> * Start/stop can be triggered from solr/admin or JMX
> * Can get the status/progress while replication is going on. It can also 
> abort an ongoing replication
> * No need to have a login into the machine 
> This issue can track the implementation of solr replication in java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to