Re: Solr: JoinAtHead seems problematic
Sure! Vào Th 6, 7 thg 8, 2020 lúc 07:33 Erick Erickson đã viết: > Well, let me know if you have to dive into that and we can wrestle it to > the ground. I suppose the short answer is “that code is correct if I > remember correctly”…. > > > On Aug 6, 2020, at 8:22 PM, Đạt Cao Mạnh > wrote: > > > > Thank Erick, > > > > I'm not fully understand it, but it kinda makes sense somehow. > > > > Thank you! > > > > On Thu, Aug 6, 2020 at 6:40 PM Erick Erickson > wrote: > > Dat: > > > > That’s a confusingly-named variable, surely needs a comment. Remembering > from a long time ago trying to work with PreferredLeader, the problem is > that you can’t _replace_ the head because that’s the one that actually is > the leader. You have to spoof that by inserting a node that points to the > leader, then making the leader go away so election takes place. IIRC (and > lots may have changed since then), you wind up with a situation where > > > > znode0 is the current leader > > znode1 points to znode0 > > znode2 _also_ points to znode0 > > znode3 points to znode1 > > znode 4 points to znode3 > > > > znode1 here was the original znode put in the queue to become the next > leader. znode2 is the one added by the code you’re looking at. When leader > election actually happens, this situation is detected and znode2 becomes > the leader and znode3 is changed to point to znode2 WARNING: This is what I > remember from code I worked on a long time ago, it may have been changed a > lot since then. But I’m fairly sure that’s what’s behind that code. > > > > Best, > > Erick > > > > > > > > > On Aug 6, 2020, at 6:18 AM, Cao Mạnh Đạt wrote: > > > > > > Hi guys, > > > > > > When I look at these lines, > > > if(joinAtHead){ > > > log.debug("Node {} trying to join election at the head", id); > > > List nodes = > OverseerTaskProcessor.getSortedElectionNodes(zkClient, shardsElectZkPath); > > > if(nodes.size() <2){ > > > leaderSeqPath = zkClient.create(shardsElectZkPath + "/" + id + > "-n_", null, > > > CreateMode.EPHEMERAL_SEQUENTIAL, false); > > > } else { > > > String firstInLine = nodes.get(1); > > > log.debug("The current head: {}", firstInLine); > > > Matcher m = LEADER_SEQ.matcher(firstInLine); > > > if (!m.matches()) { > > > throw new IllegalStateException("Could not find regex match in:" > > > + firstInLine); > > > } > > > leaderSeqPath = shardsElectZkPath + "/" + id + "-n_"+ m.group(1); > > > zkClient.create(leaderSeqPath, null, CreateMode.EPHEMERAL, false); > > > } > > > } else { > > > the line firstInLine = nodes.get(1) seems problematic to me. Why do we > get the middle of a sorted list and say that it is the first thing in line? > Should I open an issue for this? > > > > > > Thanks > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > -- > > Best regards, > > Cao Mạnh Đạt > > E-mail: caomanhdat...@gmail.com > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- *Best regards,* *Cao Mạnh Đạt* *E-mail: caomanhdat...@gmail.com *
Re: Solr: JoinAtHead seems problematic
Well, let me know if you have to dive into that and we can wrestle it to the ground. I suppose the short answer is “that code is correct if I remember correctly”…. > On Aug 6, 2020, at 8:22 PM, Đạt Cao Mạnh wrote: > > Thank Erick, > > I'm not fully understand it, but it kinda makes sense somehow. > > Thank you! > > On Thu, Aug 6, 2020 at 6:40 PM Erick Erickson wrote: > Dat: > > That’s a confusingly-named variable, surely needs a comment. Remembering from > a long time ago trying to work with PreferredLeader, the problem is that you > can’t _replace_ the head because that’s the one that actually is the leader. > You have to spoof that by inserting a node that points to the leader, then > making the leader go away so election takes place. IIRC (and lots may have > changed since then), you wind up with a situation where > > znode0 is the current leader > znode1 points to znode0 > znode2 _also_ points to znode0 > znode3 points to znode1 > znode 4 points to znode3 > > znode1 here was the original znode put in the queue to become the next > leader. znode2 is the one added by the code you’re looking at. When leader > election actually happens, this situation is detected and znode2 becomes the > leader and znode3 is changed to point to znode2 WARNING: This is what I > remember from code I worked on a long time ago, it may have been changed a > lot since then. But I’m fairly sure that’s what’s behind that code. > > Best, > Erick > > > > > On Aug 6, 2020, at 6:18 AM, Cao Mạnh Đạt wrote: > > > > Hi guys, > > > > When I look at these lines, > > if(joinAtHead){ > > log.debug("Node {} trying to join election at the head", id); > > List nodes = > > OverseerTaskProcessor.getSortedElectionNodes(zkClient, shardsElectZkPath); > > if(nodes.size() <2){ > > leaderSeqPath = zkClient.create(shardsElectZkPath + "/" + id + "-n_", > > null, > > CreateMode.EPHEMERAL_SEQUENTIAL, false); > > } else { > > String firstInLine = nodes.get(1); > > log.debug("The current head: {}", firstInLine); > > Matcher m = LEADER_SEQ.matcher(firstInLine); > > if (!m.matches()) { > > throw new IllegalStateException("Could not find regex match in:" > > + firstInLine); > > } > > leaderSeqPath = shardsElectZkPath + "/" + id + "-n_"+ m.group(1); > > zkClient.create(leaderSeqPath, null, CreateMode.EPHEMERAL, false); > > } > > } else { > > the line firstInLine = nodes.get(1) seems problematic to me. Why do we get > > the middle of a sorted list and say that it is the first thing in line? > > Should I open an issue for this? > > > > Thanks > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > -- > Best regards, > Cao Mạnh Đạt > E-mail: caomanhdat...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr: JoinAtHead seems problematic
Thank Erick, I'm not fully understand it, but it kinda makes sense somehow. Thank you! On Thu, Aug 6, 2020 at 6:40 PM Erick Erickson wrote: > Dat: > > That’s a confusingly-named variable, surely needs a comment. Remembering > from a long time ago trying to work with PreferredLeader, the problem is > that you can’t _replace_ the head because that’s the one that actually is > the leader. You have to spoof that by inserting a node that points to the > leader, then making the leader go away so election takes place. IIRC (and > lots may have changed since then), you wind up with a situation where > > znode0 is the current leader > znode1 points to znode0 > znode2 _also_ points to znode0 > znode3 points to znode1 > znode 4 points to znode3 > > znode1 here was the original znode put in the queue to become the next > leader. znode2 is the one added by the code you’re looking at. When leader > election actually happens, this situation is detected and znode2 becomes > the leader and znode3 is changed to point to znode2 WARNING: This is what I > remember from code I worked on a long time ago, it may have been changed a > lot since then. But I’m fairly sure that’s what’s behind that code. > > Best, > Erick > > > > > On Aug 6, 2020, at 6:18 AM, Cao Mạnh Đạt wrote: > > > > Hi guys, > > > > When I look at these lines, > > if(joinAtHead){ > > log.debug("Node {} trying to join election at the head", id); > > List nodes = > OverseerTaskProcessor.getSortedElectionNodes(zkClient, shardsElectZkPath); > > if(nodes.size() <2){ > > leaderSeqPath = zkClient.create(shardsElectZkPath + "/" + id + > "-n_", null, > > CreateMode.EPHEMERAL_SEQUENTIAL, false); > > } else { > > String firstInLine = nodes.get(1); > > log.debug("The current head: {}", firstInLine); > > Matcher m = LEADER_SEQ.matcher(firstInLine); > > if (!m.matches()) { > > throw new IllegalStateException("Could not find regex match in:" > > + firstInLine); > > } > > leaderSeqPath = shardsElectZkPath + "/" + id + "-n_"+ m.group(1); > > zkClient.create(leaderSeqPath, null, CreateMode.EPHEMERAL, false); > > } > > } else { > > the line firstInLine = nodes.get(1) seems problematic to me. Why do we > get the middle of a sorted list and say that it is the first thing in line? > Should I open an issue for this? > > > > Thanks > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- *Best regards,* *Cao Mạnh Đạt* *E-mail: caomanhdat...@gmail.com *
Re: Solr: JoinAtHead seems problematic
Dat: That’s a confusingly-named variable, surely needs a comment. Remembering from a long time ago trying to work with PreferredLeader, the problem is that you can’t _replace_ the head because that’s the one that actually is the leader. You have to spoof that by inserting a node that points to the leader, then making the leader go away so election takes place. IIRC (and lots may have changed since then), you wind up with a situation where znode0 is the current leader znode1 points to znode0 znode2 _also_ points to znode0 znode3 points to znode1 znode 4 points to znode3 znode1 here was the original znode put in the queue to become the next leader. znode2 is the one added by the code you’re looking at. When leader election actually happens, this situation is detected and znode2 becomes the leader and znode3 is changed to point to znode2 WARNING: This is what I remember from code I worked on a long time ago, it may have been changed a lot since then. But I’m fairly sure that’s what’s behind that code. Best, Erick > On Aug 6, 2020, at 6:18 AM, Cao Mạnh Đạt wrote: > > Hi guys, > > When I look at these lines, > if(joinAtHead){ > log.debug("Node {} trying to join election at the head", id); > List nodes = OverseerTaskProcessor.getSortedElectionNodes(zkClient, > shardsElectZkPath); > if(nodes.size() <2){ > leaderSeqPath = zkClient.create(shardsElectZkPath + "/" + id + "-n_", > null, > CreateMode.EPHEMERAL_SEQUENTIAL, false); > } else { > String firstInLine = nodes.get(1); > log.debug("The current head: {}", firstInLine); > Matcher m = LEADER_SEQ.matcher(firstInLine); > if (!m.matches()) { > throw new IllegalStateException("Could not find regex match in:" > + firstInLine); > } > leaderSeqPath = shardsElectZkPath + "/" + id + "-n_"+ m.group(1); > zkClient.create(leaderSeqPath, null, CreateMode.EPHEMERAL, false); > } > } else { > the line firstInLine = nodes.get(1) seems problematic to me. Why do we get > the middle of a sorted list and say that it is the first thing in line? > Should I open an issue for this? > > Thanks - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org