Thanks Jordan for the corner-case. Will see how to handle the same in our lock implementation.
Just one doubt, On disconnection, shouldn't ephemeral node gets deleted? Thanks, Rajat On Fri, Feb 7, 2020 at 8:10 PM Jordan Zimmerman <[email protected]> wrote: > ZooKeeper will not allow two clients to create the same ZNode. That's one > of its guarantees, if that's your question. You can only create nodes if > you're connected to a ZK instance that's part of the quorum so split brain > isn't an issue. That said, there _is_ a problem on the _client_ side. The > following can happen: > > - Client A sends a request to create an ephemeral ZNode > - The ZK instance that Client A is connected to sends the proposal, etc. > and it's successful - the ZNode is created > - Before the ZK instance can reply to Client A, there is a network > partition or other error and the _response_ to Client A fails > - Client A receives a Disconnected error before it knows whether or not it > has created its ZNode > - Client A reconnects, tries to create the ephemeral ZNode and receives > NODEEXISTS > > So, your client application would have to deal with this somehow. Curator > handles this by adding a UUID to the ZNode's name and, on reconnections, > does a getChildren() and searches for the ZNode. > > I hope this helps. > > -Jordan > > > On Feb 7, 2020, at 12:33 AM, Rajat Gangwar <[email protected]> > wrote: > > > > Hi Jordan, > > > > Each entity has an unique ID, and it will try to create ephemeral node > with > > that unique ID. But since upstream system operates in at-least-once mode, > > there is a possibility of 2 entities having same ID. Whenever that > happens > > ZK should not give success response to both calls under any > circumstances. > > > > So I just wanted to know if the above holds true in worst-case scenarios > > like, split-brain, node failures, time-outs, etc. > > > > Thanks, > > Rajat > > > > > > On Thu, Feb 6, 2020 at 6:16 PM Jordan Zimmerman < > [email protected]> > > wrote: > > > >> Rajat - I don't understand what you're proposing here. Are all entities > >> contending for the same lock? It's not possible to have multiple locks > >> under 1 ZNode. The lock recipes that Curator (or any ZK app) uses > requires > >> a unique path for each lock. In any event, If it's all the same lock > that > >> each entity is contending for then it's fine - that would be the > standard > >> lock recipe. Maybe I'm missing something? > >> > >> -Jordan > >> > >>> On Feb 5, 2020, at 1:21 AM, Rajat Gangwar <[email protected]> > >> wrote: > >>> > >>> Hi Jordan, > >>> > >>> Planning to have 1 persistent node for the application, say > >>> "/entity_locks/". And then all entities will be trying to create > >> ephemeral > >>> nodes under this parent node. > >>> > >>> We will be creating 100 million unique entities in a given day. So each > >>> unique entity will try to take the lock before persisting to > data-store. > >> So > >>> if ZK will fail to create ephemeral node if it already exists under > same > >>> parent node, then we can go with this simple implementation. > >>> > >>> Unless there are some corner cases where this might not work ? > >>> > >>> Thanks, > >>> Rajat > >>> > >>> On Tue, Feb 4, 2020 at 8:28 PM Jordan Zimmerman < > >> [email protected]> > >>> wrote: > >>> > >>>>> can I implement a lock recipe which just > >>>>> tries to create ephemeral node without any persistent nodes. > >>>> > >>>> Ephemeral nodes cannot have any children. Unless you create your lock > at > >>>> the root ("/") you'd need some parent persistent node. Is this a big > >>>> problem for you? Unless you have 1000s of unique lock paths there > >> shouldn't > >>>> be any problem with persistent parent node. > >>>> > >>>> -Jordan > >> > >> > >
