On Apr 3, 2013, at 7:18 PM, Chris Hostetter <hossman_luc...@fucit.org> 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 one. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
