[
https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645632#action_12645632
]
P E commented on SOLR-561:
--------------------------
Hi, i have a couple comments about the implementation, specifically
SnapShooter.java just pulled from TRUNK:
-------------------------------------
createSnapshot() uses the following pattern, which seems unreliable to me,
under the prospect of concurrent snapshot requests:
lockFile = new File(snapDir, directoryName + ".lock");
if (lockFile.exists()) {
return;
}
... <1> ...
lockFile.createNewFile();
... <2> ...
if (lockFile != null) {
lockFile.delete();
}
AFAIK, java.nio.channels.FileLock should be used for any type of file-based
locking of the sort for cross-vm synchronization. If you are worried about
in-vm synchronization, it might be best to just use j.u.c Locks or
synchronized{} blocks. This would remove the possiblity of junk .lock files if,
say the VM dies during <2>.
-------------------------------------
Additionally, these lines seem suspect to me. transferTo() needs to be done in
a loop for the full copy to work.
fis = new FileInputStream(file);
File destFile = new File(toDir, file.getName());
fos = new FileOutputStream(destFile);
fis.getChannel().transferTo(0, fis.available(), fos.getChannel());
destFile.setLastModified(file.lastModified());
Am i crazy or are these real problems?
> 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 (scripts)
> 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-fixes.patch, SOLR-561-fixes.patch, SOLR-561-fixes.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,
> 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.
