Noble:
Yep. but check me out on this, so far every flaw I've found has been
shooting myself in the foot! Actually, I'll make a new comment on 6691
so we have a record there.
Thanks!
Erick
On Sun, Dec 7, 2014 at 11:15 PM, Noble Paul noble.p...@gmail.com wrote:
Ideally, I'd like to just tell a
Ideally, I'd like to just tell a node to rejoin at head and have to do
nothing else.
The rejoin-at-head is an internal API which is used by other APIs (and not
exposed to others). So , in that way it is a ready-to-cook API and not a
ready-to-eat one. So, use it with caution.
The entity that
Noble:
Thanks, that'll probably solve my immediate problem, but it still
seems flawed. I should be able to specify rejoin at head on a
particular node and next time a leader is elected the node I told to
rejoin at head _should_ be the one that comes up, and that's not
guaranteed currently unless
and that's not
guaranteed currently unless one deletes the old first-in-line.
Yeah, that is what I said in the final step. ask n1 (the current leader) to
rejoin election.
The rejoin command always makes a node join at TAIL and rejoinAtHead makes
a node join right behind the current HEAD
If one
Ahhh, I wasn't too clear.
Ideally, I'd like to just tell a node to rejoin at head and have to do
nothing else. Specifically, not have to tell the old first-in-line to
rejoin at tail.
If I do _not_ do the second step, i.e. tell the old first-in-line to
rejoin at tail and _do_ tell the leader to
Let's say you have 5 nodes in n1, n2, n3, n4, n5.
n1 is the leader, n2 watches n1 etc.
Now I retryElection for n3 with joinAtHead=true. Both n2 and n3 are
watching n1. So far, so good.
My expectation is that deleting n1 would cause n3 to become leader,
but it isn't at all guaranteed. I have a
This is reminiscent of my conversation with Noble on this SOLR-6095
starting at this comment:
https://issues.apache.org/jira/browse/SOLR-6095?focusedCommentId=14032386page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14032386
Unfortunately I dropped off following it
Thanks! I somewhat remember seeing that conversation but I confess I
didn't follow it that closely.
I can't cope with looking at it any more tonight, but I'll check in
the morning. The problem I see is I don't think there's any way, once
a node is re-inserted in the queue, for another node to
