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 <rajatgangwar...@gmail.com> 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 <jor...@jordanzimmerman.com>
> 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 <rajatgangwar...@gmail.com>
>> 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 <
>> jor...@jordanzimmerman.com>
>>> 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
>>
>>
