lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_17) - Build # 2714 - Failure!
Date Thu, 04 Apr 2013 12:29:01 GMT

On Apr 3, 2013, at 7:18 PM, Chris Hostetter <> wrote:

> : My other concern about that core reload is this:
> I'm not totally following what you are saying -- is there a bug open for 
> this to track it?  (I just filled another issue that concern me 
> related to this confFile update core reload situation, SOLR-4669, and i'm 
> wondering if we can fix two birds with one stone)

Let's say you have 3 nodes, a master, a repeater, and a slave.

When you do updates and commit on the master, things will replicate to the repeater. You now
need to make the repeaters most replicatable commit the latest commit, even though a normal
trigger for this (startup, commit) has not occurred. If you don't, the right stuff won't happen
between the repeater and the slave.

In the non core reload case, we currently reach right in the ReplicationHandler and update
the last replicatable commit point on the repeater as part of installing the new index. This
is somewhat new, there used to be a commit that would push the slave gen past the leader by

In the Core reload case, it's a little trickier. If you are replicating on startup, you should
be fine - the right most replicatable commit will be set when the core reloads. But if you
don't, and just have replicate on commit, the repeater won't be ready to replicate the right
commit point to the slave.

I guess the best workaround for that at the moment is to be sure to have replicate on startup
set on your repeater.

- Mark
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message