Re: Solr: JoinAtHead seems problematic

2020-08-09 Thread Đạt Cao Mạnh
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

2020-08-06 Thread Erick Erickson
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

2020-08-06 Thread Đạt Cao Mạnh
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

2020-08-06 Thread Erick Erickson
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