[
https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-561:
------------------------------
Attachment: SOLR-561-fixes.patch
Here's an update to the "fixes" patch that fixes an issue with
setReserveDuration when called with different reserveTimes. Previously, the
new value overwrites the old, regardless of it's value. The approach to fix is
a basic spin loop (see below). Anyone see issues with this approach?
{code}
public void setReserveDuration(Long indexVersion, long reserveTime) {
long timeToSet = System.currentTimeMillis() + reserveTime;
for(;;) {
Long previousTime = reserves.put(indexVersion, timeToSet);
// this is the common success case: the older time didn't exist, or
// came before the new time.
if (previousTime == null || previousTime <= timeToSet) break;
// At this point, we overwrote a longer reservation, so we want to
restore the older one.
// the problem is that an even longer reservation may come in concurrently
// and we don't want to overwrite that one too. We simply keep retrying
in a loop
// with the maximum time value we have seen.
timeToSet = previousTime;
}
}
{code}
I think this is also a great example of where comments explaining how things
work are really needed.
> 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-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
>
>
> 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.
