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

Yonik Seeley commented on SOLR-561:
-----------------------------------

bq. Since files are transferred in one go, the master knows about the access 
time but it does not know if the transfer has ended so the lease may expire in 
between the transfer leading to a failure.

Right, as Noble pointed out, lease extension will need to be done periodically 
during the download (every N blocks written to the socket).

bq. We'll need to track the transfers individually as well.

Each file request can optionally specify the commit point it is copying.

bq. If the slave dies in between the transfer, we'll need to track that as well 
and time-out the lease appropriately.

The lease is just the current reservation mechanism, but called more often and 
with a very short reservation (on the order of seconds, not minutes I would 
think), so I don't see a need to time them out.

bq. We have been testing it with a large index (wikipedia articles, around 
7-8GB index on disk)

Cool.  Hopefully one of the test indexes contain a single file greater than 4G 
to test that we don't hit any 32 bit overflow in the stack.  If not, re-doing 
your wikipedia test with compound index format and after an optimize should do 
the trick.

> 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.4
>         Environment: All
>            Reporter: Noble Paul
>            Assignee: Shalin Shekhar Mangar
>             Fix For: 1.4
>
>         Attachments: deletion_policy.patch, SOLR-561-core.patch, 
> SOLR-561-full.patch, SOLR-561-full.patch, SOLR-561-full.patch, 
> SOLR-561-full.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, 
> SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, 
> SOLR-561.patch, SOLR-561.patch, 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 
> * From a development perspective, we can unit test it
> 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