Question about the sequential flag on create.

[Erik Holstad <er...@gmail.com>]

Hey!
I have been playing around with the queue and barrier example found on the
home page and have some questions about the code.
First of all I had trouble getting the queue example to work since the code
turns the sequence number into an int and then try to get information
from it, missing out the padding, which caused some confusion at first. So I
changed it to compare the strings themselves so you didn't have to
add the padding back on.

So the fact that you have to sort the children every time you get them is a
little bit confusing to me, does anyone have simple answer to why that is?

Regards Erik

Re: Question about the sequential flag on create.

[Erik Holstad <er...@gmail.com>]

Thanks Patrick!

Re: Question about the sequential flag on create.

[Patrick Hunt <ph...@apache.org>]

Erik, take a look at this jira:

https://issues.apache.org/jira/browse/ZOOKEEPER-423?focusedCommentId=12715558&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12715558

Patrick

Erik Holstad wrote:
> Thanks Benjamin!
> That helped, I guess you are using some kind of set where I thought you
> where using a list and I'm guessing a hashSet or so?
> Will try to have another look at the source.
> 
> Thanks guys!
> 

Re: Question about the sequential flag on create.

[Erik Holstad <er...@gmail.com>]

Thanks Benjamin!
That helped, I guess you are using some kind of set where I thought you
where using a list and I'm guessing a hashSet or so?
Will try to have another look at the source.

Thanks guys!

Re: Question about the sequential flag on create.

[Benjamin Reed <br...@yahoo-inc.com>]

the create is atomic. we just use a data structure that does not store 
the list of children in order.

ben

Erik Holstad wrote:
> Hey Patrik!
> Thanks for the reply.
> I understand all the reasons that you posted above and totally agree that
> nodes should not be sorted since you then have to pay that overhead for
> every node, even though you might not need or want it.
> I just thought that it might be possible to create a sequential node
> atomically, but I guess that is not how it works?
>
> Regards Erik
>   

Re: Question about the sequential flag on create.

[Erik Holstad <er...@gmail.com>]

Hey Patrik!
Thanks for the reply.
I understand all the reasons that you posted above and totally agree that
nodes should not be sorted since you then have to pay that overhead for
every node, even though you might not need or want it.
I just thought that it might be possible to create a sequential node
atomically, but I guess that is not how it works?

Regards Erik

Re: Question about the sequential flag on create.

[Patrick Hunt <ph...@apache.org>]

Nodes are maintained un-ordered on the server. A node can store any 
subnodes, not exclusively sequential nodes. If we added an ordering 
guarantee then then server would have to store the children sorted for 
every parent node. This is a problem for a few reasons; 1) in many cases 
you don't care about order, so all users would pay for ordering even if 
they didn't want/use it, 2) the ordering would be done by the central 
server, which would result in lower performance for everyone, not just 
the client(s)/recipe(s) that needed ordering, 3) there is no guarantee 
that the ordering you need (path) is the same order needed by all recipes.

Patrick

Erik Holstad wrote:
> Hi Mahadev!
> Yeah kinda, what I was looking for was some kind of explanation of why this
> is, since they are stored in a list
> and it seems like new children would just be appended to the list. So I
> guess my question should have been
> more along the lines of something like:
> What is it internally that causes new nodes not the be inserted in order?
> What causes the lag from getting the
> sequence number till putting it into the list?
> Or is this not at all how this works?
> 
> Regards Erik
> 

Re: Question about the sequential flag on create.

[Erik Holstad <er...@gmail.com>]

Hi Mahadev!
Yeah kinda, what I was looking for was some kind of explanation of why this
is, since they are stored in a list
and it seems like new children would just be appended to the list. So I
guess my question should have been
more along the lines of something like:
What is it internally that causes new nodes not the be inserted in order?
What causes the lag from getting the
sequence number till putting it into the list?
Or is this not at all how this works?

Regards Erik

Re: Question about the sequential flag on create.

[Mahadev Konar <ma...@yahoo-inc.com>]

Internally children of a node are not guranteed to be stored as sorted via
their names. The counter that you mention is just a version number on the
parent that is used during creation of children of a node that are created
with a Sequential flag.  It has nothing to do with how the children of a
node are stored in the data structures internally.

Hope this helps. 
mahadev


On 7/13/09 4:53 PM, "Erik Holstad" <er...@gmail.com> wrote:

> Hi Mahadev!
> Thanks for the quick reply. Yeah, I saw that in the source, but was just
> curious why that is, since it is a part of an internal
> counter structure, right?
> 
> Regards Erik

Re: Question about the sequential flag on create.

[Erik Holstad <er...@gmail.com>]

Hi Mahadev!
Thanks for the quick reply. Yeah, I saw that in the source, but was just
curious why that is, since it is a part of an internal
counter structure, right?

Regards Erik

Re: Question about the sequential flag on create.

[Mahadev Konar <ma...@yahoo-inc.com>]

Hi Erik,
 The children that you get in return are not guaranteed to be in sorted
order  and that's why they need to be sorted each time at the client side.
Hope that helps.

thanks
mahadev


On 7/13/09 4:27 PM, "Erik Holstad" <er...@gmail.com> wrote:

> Hey!
> I have been playing around with the queue and barrier example found on the
> home page and have some questions about the code.
> First of all I had trouble getting the queue example to work since the code
> turns the sequence number into an int and then try to get information
> from it, missing out the padding, which caused some confusion at first. So I
> changed it to compare the strings themselves so you didn't have to
> add the padding back on.
> 
> So the fact that you have to sort the children every time you get them is a
> little bit confusing to me, does anyone have simple answer to why that is?
> 
> Regards Erik