Jordan, Thanks for your reply. I don't intend to make changes indeed.
This comes into a question because in our case we'd like to access ourPath(private in Curator scope) so just trying to re-implement LeaderLatch and here is a little confusion. Thanks for your explanation :-) Best, tison. Jordan Zimmerman <[email protected]> 于2019年7月22日周一 下午10:25写道： > The reasoning is lost to history I think. Looking at it now it could > likely just call "getChildren()" like the watcher above it. That said, I'd > be loathe to make changes in such an old and widely used class. We'd have > to do copious testing on it. > > -JZ > > > On Jul 22, 2019, at 4:44 AM, Zili Chen <[email protected]> wrote: > > > > Hi Curators, > > > > I am reading the source code and in LeaderLatch#L592-603 it confuses > > me that when we find the previous node gone, we reset to create a new > > ephemeral sequential node for contending leadership. > > > > My question is, supposed ourPath is latch-n2 and the previous node path > > is latch-n1 where n1 is the largest number such that n1 < n2, if > > latch-n1 gone, why not just call getChildren to check if n2 is the > > leader or register another watch but we reset to create a new node? > > > > Best, > > tison. > >
