> On disconnection, shouldn't ephemeral node gets deleted? No - ephemeral nodes get deleted when the session ends. If your session is, for example, 60 seconds, you could have a small 5 second network partition and reconnect before the session expires.
-Jordan > On Feb 10, 2020, at 8:55 AM, Rajat Gangwar <[email protected]> wrote: > > 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 >>>> >>>> >> >>
