Hello.

I have a feature request I'd like to discuss: How about a call that will
give next sequential node number without node creation. Main reason is
that in many cases this would allow retries without leak on reconnect, e.g.:
Now:
1) create(SEQUENTIAL) - disconnect - retry - and you've just leaked a node
Can be
2) incrementCounter() - create(name). And you can make a retry in any
place. The worst thing that can occur is that you will have a hole in
your numbering

Another cases this can help are simple counters (no need to create nodes
at all) or simply different sequential nodes naming schema.

Best regards, Vitalii Tymchyshyn

Can you do,

Stat stat = zk.setData(somePath, new byte[] {});
stat.getVersion();

setData(...) will update the version number of the node.

This is how we use zookeeper for sequence number generation.

Sean

On Thu, Nov 17, 2011 at 1:59 AM, Vitalii Tymchyshyn <[EMAIL PROTECTED]> wrote:
> Hello.
>
> I have a feature request I'd like to discuss: How about a call that will
> give next sequential node number without node creation. Main reason is that
> in many cases this would allow retries without leak on reconnect, e.g.:
> Now:
> 1) create(SEQUENTIAL) - disconnect - retry - and you've just leaked a node
> Can be
> 2) incrementCounter() - create(name). And you can make a retry in any place.
> The worst thing that can occur is that you will have a hole in your
> numbering
>
> Another cases this can help are simple counters (no need to create nodes at
> all) or simply different sequential nodes naming schema.
>
> Best regards, Vitalii Tymchyshyn
>

17.11.11 18:54, Sean Bridges написав(ла):
> Can you do,
>
> Stat stat = zk.setData(somePath, new byte[] {});
> stat.getVersion();
>
> setData(...) will update the version number of the node.

Is it guarantied that two calls won't receive same stat? (E.g. some kind
of merging of two setData).

> This is how we use zookeeper for sequence number generation.
>
> Sean
>
> On Thu, Nov 17, 2011 at 1:59 AM, Vitalii Tymchyshyn<[EMAIL PROTECTED]>  wrote:
>> Hello.
>>
>> I have a feature request I'd like to discuss: How about a call that will
>> give next sequential node number without node creation. Main reason is that
>> in many cases this would allow retries without leak on reconnect, e.g.:
>> Now:
>> 1) create(SEQUENTIAL) - disconnect - retry - and you've just leaked a node
>> Can be
>> 2) incrementCounter() - create(name). And you can make a retry in any place.
>> The worst thing that can occur is that you will have a hole in your
>> numbering
>>
>> Another cases this can help are simple counters (no need to create nodes at
>> all) or simply different sequential nodes naming schema.
>>
>> Best regards, Vitalii Tymchyshyn
>>

No。any time，two return result will be by two update request.

2011/11/18 Vitalii Tymchyshyn <[EMAIL PROTECTED]>

> 17.11.11 18:54, Sean Bridges написав(ла):
>
>  Can you do,
>>
>> Stat stat = zk.setData(somePath, new byte[] {});
>> stat.getVersion();
>>
>> setData(...) will update the version number of the node.
>>
>
> Is it guarantied that two calls won't receive same stat? (E.g. some kind
> of merging of two setData).
>
>
>  This is how we use zookeeper for sequence number generation.
>>
>> Sean
>>
>> On Thu, Nov 17, 2011 at 1:59 AM, Vitalii Tymchyshyn<[EMAIL PROTECTED]>
>>  wrote:
>>
>>> Hello.
>>>
>>> I have a feature request I'd like to discuss: How about a call that will
>>> give next sequential node number without node creation. Main reason is
>>> that
>>> in many cases this would allow retries without leak on reconnect, e.g.:
>>> Now:
>>> 1) create(SEQUENTIAL) - disconnect - retry - and you've just leaked a
>>> node
>>> Can be
>>> 2) incrementCounter() - create(name). And you can make a retry in any
>>> place.
>>> The worst thing that can occur is that you will have a hole in your
>>> numbering
>>>
>>> Another cases this can help are simple counters (no need to create nodes
>>> at
>>> all) or simply different sequential nodes naming schema.
>>>
>>> Best regards, Vitalii Tymchyshyn
>>>
>>>
>

you can do a setdata and use the mzxid or version in the stat
structure that gets returned as the sequence id.

ben

On Thu, Nov 17, 2011 at 1:59 AM, Vitalii Tymchyshyn <[EMAIL PROTECTED]> wrote:
> Hello.
>
> I have a feature request I'd like to discuss: How about a call that will
> give next sequential node number without node creation. Main reason is that
> in many cases this would allow retries without leak on reconnect, e.g.:
> Now:
> 1) create(SEQUENTIAL) - disconnect - retry - and you've just leaked a node
> Can be
> 2) incrementCounter() - create(name). And you can make a retry in any place.
> The worst thing that can occur is that you will have a hole in your
> numbering
>
> Another cases this can help are simple counters (no need to create nodes at
> all) or simply different sequential nodes naming schema.
>
> Best regards, Vitalii Tymchyshyn
>

Hi Vitalii,

You could try create(EPHEMERAL | SEQUENTIAL) so that if you loss your session, the znode will disappear.

-Ivan

On 17 Nov 2011, at 10:59, Vitalii Tymchyshyn wrote:

> Hello.
>
> I have a feature request I'd like to discuss: How about a call that will
> give next sequential node number without node creation. Main reason is
> that in many cases this would allow retries without leak on reconnect, e.g.:
> Now:
> 1) create(SEQUENTIAL) - disconnect - retry - and you've just leaked a node
> Can be
> 2) incrementCounter() - create(name). And you can make a retry in any
> place. The worst thing that can occur is that you will have a hole in
> your numbering
>
> Another cases this can help are simple counters (no need to create nodes
> at all) or simply different sequential nodes naming schema.
>
> Best regards, Vitalii Tymchyshyn

18.11.11 11:20, Ivan Kelly написав(ла):
> Hi Vitalii,
>
> You could try create(EPHEMERAL | SEQUENTIAL) so that if you loss your session, the znode will disappear.
This will work on connection drop, but not for disconnect/reconnect AFAIK.