retreat from zookeeper

[Thomas Koch]

Hi,

as you may have noticed, I haven't been active in the ZooKeeper project 
anymore for a couple of months. I'm a full time student again since march so 
that any further activity in Hadoop/ZooKeeper would need to be auto-motivated.

Since I don't want to just fade away and I'll still give a talk about 
ZooKeeper on the BerlinBuzzWords conf (Berlin, june 6/7), I listed the reasons 
why I wouldn't like to work on the current ZooKeeper code base anymore.

I plan the following structure for my talk:

1) theoretical model / protocol of ZooKeeper
2) practical applications, projects using ZooKeeper
3) shortcomings of the current ZooKeeper code base

A tentative brain dump of part three is listed below. I appreciate any 
comments that could help me to give a balanced presentation of the ZooKeeper 
project.

If I'd need a ZooKeeper implementation right now I'd probably do a minimal-
feature rewrite in Scala + Akka. I do appreciate ZooKeeper as an invaluable 
proof-of-concept implementation and pioneer. But as in american history there 
should come others after the pioneers that don't look like Clint Eastwood 
anymore and build more tidy things.

The list:

* The code is tightly coupled
* most so called "Unit-Tests" are actualy integration tests. They run the 
whole application and test one specific functionality.

* no uniform configuration: command line parameters, system properties, 
configuration file (java properties)
* configuration properties copied to static class members

* feature bloat on fragile foundation: e.g. chroot + automatic resubscribtion 
does not work

* implementation unlike specification: allowed characters in path

* still on ant instead of maven (depends how you see ant vs. maven)

* circular object dependencies (e.g. ZooKeeper <-> ClientCnxn)

* methods with +100 lines of code and nested conditions depth well over 5

* general attitude against refactoring, no knowledge or appreciation of 
"effective java" (Josh Bloch) or "clean code" (Robert C. Martin)

* magic numbers instead of enum

* still bound to inline copy of jute (HadoopIO, avro predecessor)
* even hand coded (de)serialization in leader election

* no client-only jar. Every client gets the full server code.

* unhandy API triggered (at least) two client API wrappers: zkClient, cages

* insane amounts of code duplication

* horrible, fragile thread programming: plenty of "XYZ extends Threads" 
instead of
  - implements runnable
  - or better: executor framework
  - or much better: actors (see Akka)
  -> leads to fear of refactoring, because nobody understands all 
synchronization needs.

Best regards,

Thomas Koch, http://www.koch.ro

Re: retreat from zookeeper

[Flavio Junqueira]

Thomas, Thanks for you comments, it is an intriguing list of points you lay down below and in some sense it highlights the fact that there is still work to be done. I find it sad, though, that you decided to frame it in such a destructive way, picturing ZooKeeper as a proof-of-concept, poorly designed system. I certainly don't share your view, and the fact that people use it and invest on it makes me think that it is not as bad as you put it. There are other (and possibly better) ways of implementing the same or similar functionality, and it is great to hear that you have good ideas for how to do it. If you are able to develop such a system and form a community around it, then I'd certainly consider contributing to it. -Flavio On May 19, 2011, at 11:21 AM, Thomas Koch wrote:Hi,as you may have noticed, I haven't been active in the ZooKeeper project anymore for a couple of months. I'm a full time student again since march so that any further activity in Hadoop/ZooKeeper would need to be auto-motivated.Since I don't want to just fade away and I'll still give a talk about ZooKeeper on the BerlinBuzzWords conf (Berlin, june 6/7), I listed the reasons why I wouldn't like to work on the current ZooKeeper code base anymore.I plan the following structure for my talk:1) theoretical model / protocol of ZooKeeper2) practical applications, projects using ZooKeeper3) shortcomings of the current ZooKeeper code baseA tentative brain dump of part three is listed below. I appreciate any comments that could help me to give a balanced presentation of the ZooKeeper project.If I'd need a ZooKeeper implementation right now I'd probably do a minimal-feature rewrite in Scala + Akka. I do appreciate ZooKeeper as an invaluable proof-of-concept implementation and pioneer. But as in american history there should come others after the pioneers that don't look like Clint Eastwood anymore and build more tidy things.The list:* The code is tightly coupled* most so called "Unit-Tests" are actualy integration tests. They run the whole application and test one specific functionality.* no uniform configuration: command line parameters, system properties, configuration file (java properties)* configuration properties copied to static class members* feature bloat on fragile foundation: e.g. chroot + automatic resubscribtion does not work* implementation unlike specification: allowed characters in path* still on ant instead of maven (depends how you see ant vs. maven)* circular object dependencies (e.g. ZooKeeper <-> ClientCnxn)* methods with +100 lines of code and nested conditions depth well over 5* general attitude against refactoring, no knowledge or appreciation of "effective java" (Josh Bloch) or "clean code" (Robert C. Martin)* magic numbers instead of enum* still bound to inline copy of jute (HadoopIO, avro predecessor)* even hand coded (de)serialization in leader election* no client-only jar. Every client gets the full server code.* unhandy API triggered (at least) two client API wrappers: zkClient, cages* insane amounts of code duplication* horrible, fragile thread programming: plenty of "XYZ extends Threads" instead of  - implements runnable  - or better: executor framework  - or much better: actors (see Akka)  -> leads to fear of refactoring, because nobody understands all synchronization needs.Best regards,Thomas Koch, http://www.koch.ro flaviojunqueira research scientist f...@yahoo-inc.comdirect +34 93-183-8828 avinguda diagonal 177, 8th floor, barcelona, 08018, esphone (408) 349 3300fax (408) 349 3301 

Re: retreat from zookeeper

[Thomas Koch]

Flavio Junqueira:
> poorly designed system.

Hi Flavio,

thank you for your response. Please note that I do intend to appreciate the 
sound design of ZooKeeper in my talk. ZooKeeper is not poorly _designed_!
However it is IMHO poorly _implemented_. And I also tried to excuse this by 
pointing out that ZK seems to be the first of its kind.
ZK has explored new areas and provided insights that others can build upon 
now.

The fact that many projects use ZK shows how important its service is and 
confirms my assumption that nobody else has provided something equivalent 
before.[1]

[1] http://stackoverflow.com/questions/6047917/zookeeper-alternatives-cluster-
coordination-service

So today it's easy for me to point out shortcomings and take ZK for granted, 
but in fact it should not be forgotten that ZK is a piece of visionary work 
without precedent in its kind.

Best regards,

Thomas Koch, http://www.koch.ro

developer meeting after hadoop summit

[Benjamin Reed]

yahoo! will be sponsoring developer meetings for various projects the
day after the hadoop summit. they need a head count to reserve the
right room size and snacks.

other dev meetings i've been to generally last around 2 hours.

so, if that works for everyone i can setup a meeting on meetup. (is
that what people use these days?) i'll start a new email thread to
start collecting things to put on the agenda.

ben

dev meeting agenda

[Benjamin Reed]

please respond to this email to add things to the agenda for the dev
meeting. here are my items:

item: we need to figure out a better way of managing recipes.

Re: retreat from zookeeper

[Patrick Hunt]

Hi Thomas, I did notice that you had been making some personal changes
(all hail LI!) and I'm sorry to see you moving on. Flavio makes some
good points which I won't re-iterate, really I think it boils down to
"perfect is the enemy of the good". It's great to chase perfection,
but on a day to day basis we're all striving to make things better.

I must admit I'm personally disappointed that the netty changes have
still not gone in. I had completed these changes some time back before
you raised issues and took on the effort of driving that to
completion.  There are a number of community members, not to mention
my employer, who are disappointed with _me_ as a result. (which takes
me back to my previous "perfect enemy of good" comment).

Best of luck!

Patrick

On Thu, May 19, 2011 at 6:12 AM, Thomas Koch  wrote:
> Flavio Junqueira:
>> poorly designed system.
>
> Hi Flavio,
>
> thank you for your response. Please note that I do intend to appreciate the
> sound design of ZooKeeper in my talk. ZooKeeper is not poorly _designed_!
> However it is IMHO poorly _implemented_. And I also tried to excuse this by
> pointing out that ZK seems to be the first of its kind.
> ZK has explored new areas and provided insights that others can build upon
> now.
>
> The fact that many projects use ZK shows how important its service is and
> confirms my assumption that nobody else has provided something equivalent
> before.[1]
>
> [1] http://stackoverflow.com/questions/6047917/zookeeper-alternatives-cluster-
> coordination-service
>
> So today it's easy for me to point out shortcomings and take ZK for granted,
> but in fact it should not be forgotten that ZK is a piece of visionary work
> without precedent in its kind.
>
> Best regards,
>
> Thomas Koch, http://www.koch.ro
>

post hadoop summit dev meeting

[Benjamin Reed]

yahoo! will be sponsoring developer meetings for various projects the
day after the hadoop summit. they need a head count to reserve the
right room size and snacks.

other dev meetings i've been to generally last around 2 hours.

so, if that works for everyone i can setup a meeting on meetup. (is
that what people use these days?) i'll start a new email thread to
start collecting things to put on the agenda.

ben

dev meeting agenda

[Benjamin Reed]

please respond to this email to add things to the agenda for the dev
meeting. here are my items:

item: we need to figure out a better way of managing recipes.

Re: dev meeting agenda

[Patrick Hunt]

One agenda item: I think we should discuss the following list
(recently sent by Thomas) and boil it down into some action items
(jiras if they don't already exist) with assignee's where possible.
I've been discussing Maven support for a while, maybe this is a good
time to do it.

Patrick


* The code is tightly coupled
* most so called "Unit-Tests" are actualy integration tests. They run the
whole application and test one specific functionality.

* no uniform configuration: command line parameters, system properties,
configuration file (java properties)
* configuration properties copied to static class members

* feature bloat on fragile foundation: e.g. chroot + automatic resubscribtion
does not work

* implementation unlike specification: allowed characters in path

* still on ant instead of maven (depends how you see ant vs. maven)

* circular object dependencies (e.g. ZooKeeper <-> ClientCnxn)

* methods with +100 lines of code and nested conditions depth well over 5

* general attitude against refactoring, no knowledge or appreciation of
"effective java" (Josh Bloch) or "clean code" (Robert C. Martin)

* magic numbers instead of enum

* still bound to inline copy of jute (HadoopIO, avro predecessor)
* even hand coded (de)serialization in leader election

* no client-only jar. Every client gets the full server code.

* unhandy API triggered (at least) two client API wrappers: zkClient, cages

* insane amounts of code duplication

* horrible, fragile thread programming: plenty of "XYZ extends Threads"
instead of
 - implements runnable
 - or better: executor framework
 - or much better: actors (see Akka)
 -> leads to fear of refactoring, because nobody understands all
synchronization needs.


On Thu, May 19, 2011 at 9:17 AM, Benjamin Reed  wrote:
> please respond to this email to add things to the agenda for the dev
> meeting. here are my items:
>
> item: we need to figure out a better way of managing recipes.
>

Re: post hadoop summit dev meeting

[Patrick Hunt]

Awesome, I'm excited to get together with the community. (I'd suggest
use whatever the BAHUG uses for meetups)

Patrick

On Thu, May 19, 2011 at 9:16 AM, Benjamin Reed  wrote:
> yahoo! will be sponsoring developer meetings for various projects the
> day after the hadoop summit. they need a head count to reserve the
> right room size and snacks.
>
> other dev meetings i've been to generally last around 2 hours.
>
> so, if that works for everyone i can setup a meeting on meetup. (is
> that what people use these days?) i'll start a new email thread to
> start collecting things to put on the agenda.
>
> ben
>

Re: retreat from zookeeper

[Mahadev Konar]

Thomas,
  The issues that you point are good. I am happy to see the list. As I
had pointed out earlier I would have been happy to work with you on
some of those but I think doing everything perfect isnt how a project
evolves. If you plan to do your own implementation you will see that
you cant keep the "KEEP CODE PERFECT LOOKING" attitude. As I am sad to
see you move out of ZK am also upset to see you making claims of
ZooKeeper being a "proof of concept" implementation. Its t a proof of
concept implementation but  a product thats used in production and
what the community stands by. I would appreciate if such remarks
werent made in public lists on your own understanding of "PERFECT
LOOKING CODE".

thanks
mahadev

On Thu, May 19, 2011 at 2:21 AM, Thomas Koch  wrote:
> Hi,
>
> as you may have noticed, I haven't been active in the ZooKeeper project
> anymore for a couple of months. I'm a full time student again since march so
> that any further activity in Hadoop/ZooKeeper would need to be auto-motivated.
>
> Since I don't want to just fade away and I'll still give a talk about
> ZooKeeper on the BerlinBuzzWords conf (Berlin, june 6/7), I listed the reasons
> why I wouldn't like to work on the current ZooKeeper code base anymore.
>
> I plan the following structure for my talk:
>
> 1) theoretical model / protocol of ZooKeeper
> 2) practical applications, projects using ZooKeeper
> 3) shortcomings of the current ZooKeeper code base
>
> A tentative brain dump of part three is listed below. I appreciate any
> comments that could help me to give a balanced presentation of the ZooKeeper
> project.
>
> If I'd need a ZooKeeper implementation right now I'd probably do a minimal-
> feature rewrite in Scala + Akka. I do appreciate ZooKeeper as an invaluable
> proof-of-concept implementation and pioneer. But as in american history there
> should come others after the pioneers that don't look like Clint Eastwood
> anymore and build more tidy things.
>
> The list:
>
> * The code is tightly coupled
> * most so called "Unit-Tests" are actualy integration tests. They run the
> whole application and test one specific functionality.
>
> * no uniform configuration: command line parameters, system properties,
> configuration file (java properties)
> * configuration properties copied to static class members
>
> * feature bloat on fragile foundation: e.g. chroot + automatic resubscribtion
> does not work
>
> * implementation unlike specification: allowed characters in path
>
> * still on ant instead of maven (depends how you see ant vs. maven)
>
> * circular object dependencies (e.g. ZooKeeper <-> ClientCnxn)
>
> * methods with +100 lines of code and nested conditions depth well over 5
>
> * general attitude against refactoring, no knowledge or appreciation of
> "effective java" (Josh Bloch) or "clean code" (Robert C. Martin)
>
> * magic numbers instead of enum
>
> * still bound to inline copy of jute (HadoopIO, avro predecessor)
> * even hand coded (de)serialization in leader election
>
> * no client-only jar. Every client gets the full server code.
>
> * unhandy API triggered (at least) two client API wrappers: zkClient, cages
>
> * insane amounts of code duplication
>
> * horrible, fragile thread programming: plenty of "XYZ extends Threads"
> instead of
>  - implements runnable
>  - or better: executor framework
>  - or much better: actors (see Akka)
>  -> leads to fear of refactoring, because nobody understands all
> synchronization needs.
>
> Best regards,
>
> Thomas Koch, http://www.koch.ro
>



-- 
thanks
mahadev
@mahadevkonar

Re: bookkeeper release

[Dhruba Borthakur]

It would be good to have a release before the Hadoop summit. Hopefully, we
will be able to rope in new people interested in bookkeeper development!!!

-dhruba

On Thu, May 19, 2011 at 8:28 AM, Benjamin Reed  wrote:

> yeah i guess i was just assuming we would follow zookeeper conventions as
> closely as possible.
>
> ben
>
>
> On Thu, May 19, 2011 at 8:11 AM, Flavio Junqueira wrote:
>
>> +1, Mid-june for a release sounds good to me.
>>
>> I'm not sure about the version because I don't think we have agreed upon a
>> numbering scheme. I'm happy to have major and minor only as you propose,
>> though.
>>
>> -Flavio
>>
>>
>> On May 19, 2011, at 5:01 PM, Benjamin Reed wrote:
>>
>> i think we should push to get a bookkeeper release out. i think the
>> main thing we need is to put together some doc. should we call it 0.1?
>> target mid june?
>>
>> ben
>>
>>
>>   *flavio*
>> *junqueira*
>>
>> research scientist
>>
>> f...@yahoo-inc.com
>> direct +34 93-183-8828
>>
>> avinguda diagonal 177, 8th floor, barcelona, 08018, es
>> phone (408) 349 3300fax (408) 349 3301
>>
>>
>>
>


-- 
Connect to me at http://www.facebook.com/dhruba

Re: CHANGES.txt

[Dhruba Borthakur]

The CHNAGES.txt file has served us well in the hadoop land as well.

+1.

dhruba


On Thu, May 19, 2011 at 7:59 AM, Benjamin Reed  wrote:

> i agree. we need to add a CHANGES.txt.
>
> ben
>
> On Thu, May 19, 2011 at 1:35 AM, Flavio Junqueira 
> wrote:
> > Hi, One quick question: should we have a CHANGES.txt file containing
> > committed jiras as we have for zookeeper? If so, should it be per
> component
> > or global?
> >
> > My preference is to have this file updated upon every commit and have it
> on
> > the project root, covering all components. This way will be easier when
> > producing new releases.
> >
> > -Flavio
> >
> >
>



-- 
Connect to me at http://www.facebook.com/dhruba

Jira and dev list

[Flavio Junqueira]

I think jira updates are not being sent to the list. How do we fix it?

-Flavio

commit process for zookeeper

[Benjamin Reed]

i've added a wiki page to document the commit process. they are the
steps i follow, so hopefully i didn't miss anything :) i think it
would be helpful for the new committers as they do their first
commits. (welcome! thanks for sharing the work!)

https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes

Re: commit process for zookeeper

[Michi Mutsuzaki]

Hi Ben,

Thank you for putting this up! I find it very helpful.

--Michi

On 5/19/11 12:17 PM, "Benjamin Reed"  wrote:

> i've added a wiki page to document the commit process. they are the
> steps i follow, so hopefully i didn't miss anything :) i think it
> would be helpful for the new committers as they do their first
> commits. (welcome! thanks for sharing the work!)
> 
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
> 

Re: commit process for zookeeper

[Patrick Hunt]

Great idea Ben, thanks.

On Thu, May 19, 2011 at 12:30 PM, Michi Mutsuzaki  wrote:
> Hi Ben,
>
> Thank you for putting this up! I find it very helpful.
>
> --Michi
>
> On 5/19/11 12:17 PM, "Benjamin Reed"  wrote:
>
>> i've added a wiki page to document the commit process. they are the
>> steps i follow, so hopefully i didn't miss anything :) i think it
>> would be helpful for the new committers as they do their first
>> commits. (welcome! thanks for sharing the work!)
>>
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
>>
>
>

[jira] [Commented] (ZOOKEEPER-1058) fix typo in opToString for getData

[Benjamin Reed (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036443#comment-13036443
 ] 

Benjamin Reed commented on ZOOKEEPER-1058:
--

fortunately, this patch isn't likely to go stale :) it will be good practice 
for you.

> fix typo in opToString for getData
> --
>
> Key: ZOOKEEPER-1058
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1058
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Camille Fournier
>Assignee: Camille Fournier
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1058
>
>
> fix Request getData to print that instead of getDate

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ANNOUNCE] ZooKeeper Committer: Camille Fournier

[Patrick Hunt]

Hi folks,

The Apache ZooKeeper PMC recently extended committer karma to Camille
and she has accepted.  Welcome aboard Camille!

Patrick

[jira] [Commented] (ZOOKEEPER-784) server-side functionality for read-only mode

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036465#comment-13036465
 ] 

Hadoop QA commented on ZOOKEEPER-784:
-

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12478176/ZOOKEEPER-784.patch
  against trunk revision 1103811.

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 11 new or modified tests.

+1 javadoc.  The javadoc tool did not generate any warning messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

+1 findbugs.  The patch does not introduce any new Findbugs (version 1.3.9) 
warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

+1 core tests.  The patch passed core unit tests.

+1 contrib tests.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/277//testReport/
Findbugs warnings: 
https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/277//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/277//console

This message is automatically generated.

> server-side functionality for read-only mode
> 
>
> Key: ZOOKEEPER-784
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-784
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: server
>Reporter: Sergey Doroshenko
>Assignee: Sergey Doroshenko
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
> ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
> ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
> ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
> ZOOKEEPER-784.patch, ZOOKEEPER-784.patch
>
>
> As per http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode , create 
> ReadOnlyZooKeeperServer which comes into play when peer is partitioned.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [ANNOUNCE] ZooKeeper Committer: Camille Fournier

[Mahadev Konar]

Welcome aboard Camille! Look forward to more and more participation from you!

-- 
thanks
mahadev
@mahadevkonar

Re: [ANNOUNCE] ZooKeeper Committer: Camille Fournier

[Mathias Herberts]

On Thu, May 19, 2011 at 22:55, Patrick Hunt  wrote:
> Hi folks,
>
> The Apache ZooKeeper PMC recently extended committer karma to Camille
> and she has accepted.  Welcome aboard Camille!

Congrats!

[jira] [Commented] (ZOOKEEPER-784) server-side functionality for read-only mode

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036583#comment-13036583
 ] 

Patrick Hunt commented on ZOOKEEPER-784:


Great to see all the work on this one, thanks everyone and esp Sergey!

> server-side functionality for read-only mode
> 
>
> Key: ZOOKEEPER-784
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-784
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: server
>Reporter: Sergey Doroshenko
>Assignee: Sergey Doroshenko
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
> ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
> ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
> ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
> ZOOKEEPER-784.patch, ZOOKEEPER-784.patch
>
>
> As per http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode , create 
> ReadOnlyZooKeeperServer which comes into play when peer is partitioned.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely

[Benjamin Reed (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036601#comment-13036601
 ] 

Benjamin Reed commented on ZOOKEEPER-965:
-

i'm almost done with the review. (it's a big patch!!!) there is a high level 
issue i'd like to bring up: i don't think the check request should return 
anything because if the check succeeds, you already know the information that 
is returned. (it's what you expected.) if the check fails, you just get an 
error code. if check doesn't return anything, we can either drop it if it 
succeeds in PrepRequestProcesor or propogate an error. this simplifies the rest 
of the pipeline a bit because they will not have to care about the check op.


> Need a multi-update command to allow multiple znodes to be updated safely
> -
>
> Key: ZOOKEEPER-965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.3.3
>Reporter: Ted Dunning
>Assignee: Ted Dunning
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a 
> list of create, delete, update or check objects each of which has a desired 
> version or file state in the case of create.  If all of the version and 
> existence constraints can be satisfied, then all updates will be done 
> atomically.
> Two API styles have been suggested.  One has a list as above and the other 
> style has a "Transaction" that allows builder-like methods to build a set of 
> updates and a commit method to finalize the transaction.  This can trivially 
> be reduced to the first kind of API so the list based API style should be 
> considered the primitive and the builder style should be implemented as 
> syntactic sugar.
> The total size of all the data in all updates and creates in a single 
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.  
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form, 
> the code should be slightly extended to convert a list of operations to 
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be 
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at 
> https://github.com/tdunning/zookeeper  and am happy to extend committer 
> status to anyone who agrees to donate their code back to Apache.  The final 
> patch will be attached to this bug as normal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely

[Marshall McMullen (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036605#comment-13036605
 ] 

Marshall McMullen commented on ZOOKEEPER-965:
-

Benjamin,

I completely agree. At my company our internal code that uses zookeeper and the 
new multi op support does exactly what you suggest. We didn't see any need for 
the return from a check op, so we ignore it completely. I think your suggestion 
is a good one.

> Need a multi-update command to allow multiple znodes to be updated safely
> -
>
> Key: ZOOKEEPER-965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.3.3
>Reporter: Ted Dunning
>Assignee: Ted Dunning
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a 
> list of create, delete, update or check objects each of which has a desired 
> version or file state in the case of create.  If all of the version and 
> existence constraints can be satisfied, then all updates will be done 
> atomically.
> Two API styles have been suggested.  One has a list as above and the other 
> style has a "Transaction" that allows builder-like methods to build a set of 
> updates and a commit method to finalize the transaction.  This can trivially 
> be reduced to the first kind of API so the list based API style should be 
> considered the primitive and the builder style should be implemented as 
> syntactic sugar.
> The total size of all the data in all updates and creates in a single 
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.  
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form, 
> the code should be slightly extended to convert a list of operations to 
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be 
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at 
> https://github.com/tdunning/zookeeper  and am happy to extend committer 
> status to anyone who agrees to donate their code back to Apache.  The final 
> patch will be attached to this bug as normal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely

[Ted Dunning (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036609#comment-13036609
 ] 

Ted Dunning commented on ZOOKEEPER-965:
---

Well, I am not entirely sure about ignoring the check result.

First, the order and count of results is very handy to make sure that you can 
attach results back to which operation caused the result.  I realize that there 
is no conditionality here but one-for-one correspondence in the results is very 
nice.  The idea that multi transforms ops into results is nice and simple.

It is true that it is hard to imagine that the Stat structure that comes back 
has any new information in it.  I would be happy if the client inserts 
place-holder results.  My original motivation was to design check as if it were 
a call to an exists method.  As you point out, the client probably have done 
that already.  

Would you be happy with the client side insertion only?  This would give all of 
the economies you want, but would preserve a simpler facade for the user.


> Need a multi-update command to allow multiple znodes to be updated safely
> -
>
> Key: ZOOKEEPER-965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.3.3
>Reporter: Ted Dunning
>Assignee: Ted Dunning
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a 
> list of create, delete, update or check objects each of which has a desired 
> version or file state in the case of create.  If all of the version and 
> existence constraints can be satisfied, then all updates will be done 
> atomically.
> Two API styles have been suggested.  One has a list as above and the other 
> style has a "Transaction" that allows builder-like methods to build a set of 
> updates and a commit method to finalize the transaction.  This can trivially 
> be reduced to the first kind of API so the list based API style should be 
> considered the primitive and the builder style should be implemented as 
> syntactic sugar.
> The total size of all the data in all updates and creates in a single 
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.  
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form, 
> the code should be slightly extended to convert a list of operations to 
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be 
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at 
> https://github.com/tdunning/zookeeper  and am happy to extend committer 
> status to anyone who agrees to donate their code back to Apache.  The final 
> patch will be attached to this bug as normal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely

[Marshall McMullen (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036642#comment-13036642
 ] 

Marshall McMullen commented on ZOOKEEPER-965:
-

Ted brings up a very valid point. All of the code in the server and both Java 
and C clients always assume the one-to-one correspondence between the number of 
ops submitted and the number of results. 

But, I'm not sure it needs to be a Stat that we put into the results. It could 
just have a placeholder or boolean value (which would always been one on a 
successful multi-op). 

Ted, I'm not sure I understand what you mean by client-side insertion only. Can 
you elaborate on what that would entail? Also, I'd be hesitant to do anything 
that makes the server-side (or the C client) processing any more complex or 
difficult than it already is

> Need a multi-update command to allow multiple znodes to be updated safely
> -
>
> Key: ZOOKEEPER-965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.3.3
>Reporter: Ted Dunning
>Assignee: Ted Dunning
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a 
> list of create, delete, update or check objects each of which has a desired 
> version or file state in the case of create.  If all of the version and 
> existence constraints can be satisfied, then all updates will be done 
> atomically.
> Two API styles have been suggested.  One has a list as above and the other 
> style has a "Transaction" that allows builder-like methods to build a set of 
> updates and a commit method to finalize the transaction.  This can trivially 
> be reduced to the first kind of API so the list based API style should be 
> considered the primitive and the builder style should be implemented as 
> syntactic sugar.
> The total size of all the data in all updates and creates in a single 
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.  
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form, 
> the code should be slightly extended to convert a list of operations to 
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be 
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at 
> https://github.com/tdunning/zookeeper  and am happy to extend committer 
> status to anyone who agrees to donate their code back to Apache.  The final 
> patch will be attached to this bug as normal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Review Request: ZOOKEEPER-965 - Add multi operation

[Benjamin Reed]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/739/#review689
---



src/c/include/zookeeper.h


shouldn't this be a union



src/c/include/zookeeper.h


it isn't clear to me that we should expose check outside of a 
multitransaction.



src/java/main/org/apache/zookeeper/Transaction.java


should we also have an asynchronous version?



src/java/main/org/apache/zookeeper/ZooKeeper.java


i think we also need an asynchronous version.



src/java/main/org/apache/zookeeper/server/DataTree.java


if stat didn't return anything, we could skip this altogether. if we are 
going to return something, should we return more than the version?



src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java


i don't think we want to log this at all do we?



src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java


don't use tabs. spaces!



src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java


i think we are only half atomic here. if the multi txn fails half way 
through, it will not be applied to the database, but we will still have 
recorded it as pending, so we may fail later changes.

for example, if there is a create for a znode that would otherwise succeed, 
but fails do to a later (in the multi txn) check failing. there will be a 
pending change record created, so even though the create failed, later creates 
to that znode will result in a node exists error.



src/zookeeper.jute


i don't think we should use TxnHeader since all we need is the type.


- Benjamin


On 2011-05-19 02:13:14, Ted Dunning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/739/
> ---
> 
> (Updated 2011-05-19 02:13:14)
> 
> 
> Review request for zookeeper and Benjamin Reed.
> 
> 
> Summary
> ---
> 
> This mega-patch adds the multi-op capability to ZK.  This allows a batch of 
> create, delete, update or version-check operations to 
> succeed or fail together.   Both C and java bindings are provided.
> 
> 
> This addresses bug ZOOKEEPER-965.
> https://issues.apache.org/jira/browse/ZOOKEEPER-965
> 
> 
> Diffs
> -
> 
>   src/c/Makefile.am 65830fe 
>   src/c/include/proto.h 843032f 
>   src/c/include/zookeeper.h c055edb 
>   src/c/src/zookeeper.c db715b0 
>   src/c/tests/TestMulti.cc PRE-CREATION 
>   src/c/tests/TestOperations.cc f9441ea 
>   src/c/tests/ZKMocks.cc a75dce6 
>   src/java/main/org/apache/zookeeper/MultiResponse.java PRE-CREATION 
>   src/java/main/org/apache/zookeeper/MultiTransactionRecord.java PRE-CREATION 
>   src/java/main/org/apache/zookeeper/Op.java PRE-CREATION 
>   src/java/main/org/apache/zookeeper/OpResult.java PRE-CREATION 
>   src/java/main/org/apache/zookeeper/Transaction.java PRE-CREATION 
>   src/java/main/org/apache/zookeeper/ZooDefs.java 832976f 
>   src/java/main/org/apache/zookeeper/ZooKeeper.java 00b4012 
>   src/java/main/org/apache/zookeeper/server/DataTree.java d16537e 
>   src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java 
> 2538cf7 
>   src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 50f208d 
>   src/java/main/org/apache/zookeeper/server/Request.java a5c57e2 
>   src/java/main/org/apache/zookeeper/server/RequestProcessor.java 5c3e8ff 
>   src/java/main/org/apache/zookeeper/server/TraceFormatter.java 8ece929 
>   src/java/main/org/apache/zookeeper/server/package.html 3ec7656 
>   src/java/main/org/apache/zookeeper/server/quorum/CommitProcessor.java 
> 49affd5 
>   src/java/main/org/apache/zookeeper/server/util/SerializeUtils.java 0ad4dd6 
>   src/java/test/org/apache/zookeeper/MultiResponseTest.java PRE-CREATION 
>   src/java/test/org/apache/zookeeper/MultiTransactionRecordTest.java 
> PRE-CREATION 
>   src/java/test/org/apache/zookeeper/test/MultiTransactionTest.java 
> PRE-CREATION 
>   src/zookeeper.jute 7d96f32 
> 
> Diff: https://reviews.apache.org/r/739/diff
> 
> 
> Testing
> ---
> 
> A number of unit tests have been implemented.  Test coverage is very good.
> 
> A sample application has been written to do simple operations on a graph of 
> nodes.
> 
> 
> Thanks,
> 
> Ted
> 
>

[jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely

[jirapos...@reviews.apache.org (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036664#comment-13036664
 ] 

jirapos...@reviews.apache.org commented on ZOOKEEPER-965:
-


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/739/#review689
---



src/c/include/zookeeper.h


shouldn't this be a union



src/c/include/zookeeper.h


it isn't clear to me that we should expose check outside of a 
multitransaction.



src/java/main/org/apache/zookeeper/Transaction.java


should we also have an asynchronous version?



src/java/main/org/apache/zookeeper/ZooKeeper.java


i think we also need an asynchronous version.



src/java/main/org/apache/zookeeper/server/DataTree.java


if stat didn't return anything, we could skip this altogether. if we are 
going to return something, should we return more than the version?



src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java


i don't think we want to log this at all do we?



src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java


don't use tabs. spaces!



src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java


i think we are only half atomic here. if the multi txn fails half way 
through, it will not be applied to the database, but we will still have 
recorded it as pending, so we may fail later changes.

for example, if there is a create for a znode that would otherwise succeed, 
but fails do to a later (in the multi txn) check failing. there will be a 
pending change record created, so even though the create failed, later creates 
to that znode will result in a node exists error.



src/zookeeper.jute


i don't think we should use TxnHeader since all we need is the type.


- Benjamin


On 2011-05-19 02:13:14, Ted Dunning wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/739/
bq.  ---
bq.  
bq.  (Updated 2011-05-19 02:13:14)
bq.  
bq.  
bq.  Review request for zookeeper and Benjamin Reed.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  This mega-patch adds the multi-op capability to ZK.  This allows a batch 
of create, delete, update or version-check operations to 
bq.  succeed or fail together.   Both C and java bindings are provided.
bq.  
bq.  
bq.  This addresses bug ZOOKEEPER-965.
bq.  https://issues.apache.org/jira/browse/ZOOKEEPER-965
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq.src/c/Makefile.am 65830fe 
bq.src/c/include/proto.h 843032f 
bq.src/c/include/zookeeper.h c055edb 
bq.src/c/src/zookeeper.c db715b0 
bq.src/c/tests/TestMulti.cc PRE-CREATION 
bq.src/c/tests/TestOperations.cc f9441ea 
bq.src/c/tests/ZKMocks.cc a75dce6 
bq.src/java/main/org/apache/zookeeper/MultiResponse.java PRE-CREATION 
bq.src/java/main/org/apache/zookeeper/MultiTransactionRecord.java 
PRE-CREATION 
bq.src/java/main/org/apache/zookeeper/Op.java PRE-CREATION 
bq.src/java/main/org/apache/zookeeper/OpResult.java PRE-CREATION 
bq.src/java/main/org/apache/zookeeper/Transaction.java PRE-CREATION 
bq.src/java/main/org/apache/zookeeper/ZooDefs.java 832976f 
bq.src/java/main/org/apache/zookeeper/ZooKeeper.java 00b4012 
bq.src/java/main/org/apache/zookeeper/server/DataTree.java d16537e 
bq.src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java 
2538cf7 
bq.src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 
50f208d 
bq.src/java/main/org/apache/zookeeper/server/Request.java a5c57e2 
bq.src/java/main/org/apache/zookeeper/server/RequestProcessor.java 5c3e8ff 
bq.src/java/main/org/apache/zookeeper/server/TraceFormatter.java 8ece929 
bq.src/java/main/org/apache/zookeeper/server/package.html 3ec7656 
bq.src/java/main/org/apache/zookeeper/server/quorum/CommitProcessor.java 
49affd5 
bq.src/java/main/org/apache/zookeeper/server/util/SerializeUtils.java 
0ad4dd6 
bq.src/java/test/org/apache/zookeeper/MultiResponseTest.java PRE-CREATION 
bq.src/java/test/org/apache/zookeeper/MultiTransactionRecordTest.java 
PRE-CREATION 
bq.src/java/test/org/apache/zookeeper/test/MultiTransactionTest.java 
PRE-CREATION 
bq.src/zoo

[jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely

[Benjamin Reed (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1303#comment-1303
 ] 

Benjamin Reed commented on ZOOKEEPER-965:
-

yeah, i was thinking along the same lines as you two: a boolean place holder 
would work out nicely.

> Need a multi-update command to allow multiple znodes to be updated safely
> -
>
> Key: ZOOKEEPER-965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.3.3
>Reporter: Ted Dunning
>Assignee: Ted Dunning
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, 
> ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch
>
>
> The basic idea is to have a single method called "multi" that will accept a 
> list of create, delete, update or check objects each of which has a desired 
> version or file state in the case of create.  If all of the version and 
> existence constraints can be satisfied, then all updates will be done 
> atomically.
> Two API styles have been suggested.  One has a list as above and the other 
> style has a "Transaction" that allows builder-like methods to build a set of 
> updates and a commit method to finalize the transaction.  This can trivially 
> be reduced to the first kind of API so the list based API style should be 
> considered the primitive and the builder style should be implemented as 
> syntactic sugar.
> The total size of all the data in all updates and creates in a single 
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.  
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form, 
> the code should be slightly extended to convert a list of operations to 
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be 
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at 
> https://github.com/tdunning/zookeeper  and am happy to extend committer 
> status to anyone who agrees to donate their code back to Apache.  The final 
> patch will be attached to this bug as normal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (ZOOKEEPER-1065) Possible timing issue in embedded server

[Gunnar Wagenknecht (JIRA)]

Possible timing issue in embedded server


 Key: ZOOKEEPER-1065
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1065
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client, server
Affects Versions: 3.3.3
 Environment: Windows 7, 32bit, Core2 Duo T9300, JDK 1.6.0_24, 
ZooKeeper data on 500GB hybrid Seagate HDD with 4GB SSD cache
Reporter: Gunnar Wagenknecht


I have an application that uses ZooKeeper. There is an ensemble in
production. But in order to simplify development the application will
start an embedded ZooKeeper server when started in development mode. We
are experiencing a timing issue with ZooKeeper 3.3.3 and I was wondering
if this is allowed to be happen or if we did something wrong when
starting the embedded server.


Basically, we have a watch registered using an #exists call and watch
code like the following.
{code}
@Override
public void process(final WatchedEvent event) {
  switch (event.getType()) {
...
case NodeCreated:
  pathCreated(event.getPath());
  break;
...
  }
}

@Override
protected void pathCreated(final String path) {
  // process events only for this node
  if (!isMyPath(path))
return;
  try {
loadNode(); // calls zk.getData(String, Watcher, Stat)
  } catch (final Exception e) {
// got NoNodeException here (but not when debugging)
log(..., e)
  }
}
{code}


>From inspecting the logs we noticed a NoNodeException. When setting
breakpoints on #loadNode and stepping through we don't get the
exception. But when setting a breakpoint on #log only we got a hit and
could confirm the issue this way.

The path is actually some levels deep. All the parent paths don't exist
either so they are created as well. However, no exception is thrown fro
them. The sequence is as follows.

{noformat}
/l1  --> watch triggered, getData, no exception
/l1/l2  --> watch triggered, getData, no exception
/l1/l2/l3  --> watch triggered, getData, no exception
/l1/l2/l3/l4  --> watch triggered, getData, no exception
/l1/l2/l3/l4/l5  --> watch triggered, getData, no exception
/l1/l2/l3/l4/l5/l6  --> watch triggered, getData, NoNodeException
{noformat}

The only difference is that all paths up to including l5 do not actually
have any data. Only l6 has some data. Could there be some latency issues?

For completeness, the embedded server is started as follows.
{code}
// disable LOG4J JMX stuff
System.setProperty("zookeeper.jmx.log4j.disable", Boolean.TRUE.toString());

// get directories
final File dataDir = new File(config.getDataLogDir());
final File snapDir = new File(config.getDataDir());

// clean old logs
PurgeTxnLog.purge(dataDir, snapDir, 3);

// create standalone server
zkServer = new ZooKeeperServer();
zkServer.setTxnLogFactory(new FileTxnSnapLog(dataDir, snapDir));
zkServer.setTickTime(config.getTickTime());
zkServer.setMinSessionTimeout(config.getMinSessionTimeout());
zkServer.setMaxSessionTimeout(config.getMaxSessionTimeout());

factory = new NIOServerCnxn.Factory(config.getClientPortAddress(),
config.getMaxClientCnxns());

// start server
LOG.info("Starting ZooKeeper standalone server.");
try {
  factory.startup(zkServer);
} catch (final InterruptedException e) {
  LOG.warn("Interrupted during server start.", e);
  Thread.currentThread().interrupt();
}
{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1065) Possible timing issue in embedded server

[Gunnar Wagenknecht (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gunnar Wagenknecht updated ZOOKEEPER-1065:
--

Attachment: zookeeper-nonode-issue.log

I attached the complete DEBUG log of the procedure. This includes the behavior 
of our application start procedure. The exception is logged in line 190 {{WARN  
o.e.g.c.i.p.ZooKeeperBasedPreferences - Error refreshing node ...}}.

> Possible timing issue in embedded server
> 
>
> Key: ZOOKEEPER-1065
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1065
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client, server
>Affects Versions: 3.3.3
> Environment: Windows 7, 32bit, Core2 Duo T9300, JDK 1.6.0_24, 
> ZooKeeper data on 500GB hybrid Seagate HDD with 4GB SSD cache
>Reporter: Gunnar Wagenknecht
> Attachments: zookeeper-nonode-issue.log
>
>
> I have an application that uses ZooKeeper. There is an ensemble in
> production. But in order to simplify development the application will
> start an embedded ZooKeeper server when started in development mode. We
> are experiencing a timing issue with ZooKeeper 3.3.3 and I was wondering
> if this is allowed to be happen or if we did something wrong when
> starting the embedded server.
> Basically, we have a watch registered using an #exists call and watch
> code like the following.
> {code}
> @Override
> public void process(final WatchedEvent event) {
>   switch (event.getType()) {
> ...
> case NodeCreated:
>   pathCreated(event.getPath());
>   break;
> ...
>   }
> }
> @Override
> protected void pathCreated(final String path) {
>   // process events only for this node
>   if (!isMyPath(path))
> return;
>   try {
> loadNode(); // calls zk.getData(String, Watcher, Stat)
>   } catch (final Exception e) {
> // got NoNodeException here (but not when debugging)
> log(..., e)
>   }
> }
> {code}
> From inspecting the logs we noticed a NoNodeException. When setting
> breakpoints on #loadNode and stepping through we don't get the
> exception. But when setting a breakpoint on #log only we got a hit and
> could confirm the issue this way.
> The path is actually some levels deep. All the parent paths don't exist
> either so they are created as well. However, no exception is thrown fro
> them. The sequence is as follows.
> {noformat}
> /l1  --> watch triggered, getData, no exception
> /l1/l2  --> watch triggered, getData, no exception
> /l1/l2/l3  --> watch triggered, getData, no exception
> /l1/l2/l3/l4  --> watch triggered, getData, no exception
> /l1/l2/l3/l4/l5  --> watch triggered, getData, no exception
> /l1/l2/l3/l4/l5/l6  --> watch triggered, getData, NoNodeException
> {noformat}
> The only difference is that all paths up to including l5 do not actually
> have any data. Only l6 has some data. Could there be some latency issues?
> For completeness, the embedded server is started as follows.
> {code}
> // disable LOG4J JMX stuff
> System.setProperty("zookeeper.jmx.log4j.disable", Boolean.TRUE.toString());
> // get directories
> final File dataDir = new File(config.getDataLogDir());
> final File snapDir = new File(config.getDataDir());
> // clean old logs
> PurgeTxnLog.purge(dataDir, snapDir, 3);
> // create standalone server
> zkServer = new ZooKeeperServer();
> zkServer.setTxnLogFactory(new FileTxnSnapLog(dataDir, snapDir));
> zkServer.setTickTime(config.getTickTime());
> zkServer.setMinSessionTimeout(config.getMinSessionTimeout());
> zkServer.setMaxSessionTimeout(config.getMaxSessionTimeout());
> factory = new NIOServerCnxn.Factory(config.getClientPortAddress(),
> config.getMaxClientCnxns());
> // start server
> LOG.info("Starting ZooKeeper standalone server.");
> try {
>   factory.startup(zkServer);
> } catch (final InterruptedException e) {
>   LOG.warn("Interrupted during server start.", e);
>   Thread.currentThread().interrupt();
> }
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1065) Possible timing issue in embedded server

[Gunnar Wagenknecht (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036700#comment-13036700
 ] 

Gunnar Wagenknecht commented on ZOOKEEPER-1065:
---

{noformat}
Am 19.05.2011 21:14, schrieb Patrick Hunt:
> Hi Gunnar this is great detective work. It certainly sounds like it
> might be some timing issue or possible bug in ZK exposed by this
> embedded case. A few questions:
> 
> 1) in this dev/embedded case you only have a single zk server, correct?
{noformat}

Single ZK server.

{noformat}
> 2) you have 2 clients in this case, one creating the znode and one
> watching (vs say a single client doing both)
{noformat}

It's a single client which connects to "localhost" single server.



> Possible timing issue in embedded server
> 
>
> Key: ZOOKEEPER-1065
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1065
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client, server
>Affects Versions: 3.3.3
> Environment: Windows 7, 32bit, Core2 Duo T9300, JDK 1.6.0_24, 
> ZooKeeper data on 500GB hybrid Seagate HDD with 4GB SSD cache
>Reporter: Gunnar Wagenknecht
> Attachments: zookeeper-nonode-issue.log
>
>
> I have an application that uses ZooKeeper. There is an ensemble in
> production. But in order to simplify development the application will
> start an embedded ZooKeeper server when started in development mode. We
> are experiencing a timing issue with ZooKeeper 3.3.3 and I was wondering
> if this is allowed to be happen or if we did something wrong when
> starting the embedded server.
> Basically, we have a watch registered using an #exists call and watch
> code like the following.
> {code}
> @Override
> public void process(final WatchedEvent event) {
>   switch (event.getType()) {
> ...
> case NodeCreated:
>   pathCreated(event.getPath());
>   break;
> ...
>   }
> }
> @Override
> protected void pathCreated(final String path) {
>   // process events only for this node
>   if (!isMyPath(path))
> return;
>   try {
> loadNode(); // calls zk.getData(String, Watcher, Stat)
>   } catch (final Exception e) {
> // got NoNodeException here (but not when debugging)
> log(..., e)
>   }
> }
> {code}
> From inspecting the logs we noticed a NoNodeException. When setting
> breakpoints on #loadNode and stepping through we don't get the
> exception. But when setting a breakpoint on #log only we got a hit and
> could confirm the issue this way.
> The path is actually some levels deep. All the parent paths don't exist
> either so they are created as well. However, no exception is thrown fro
> them. The sequence is as follows.
> {noformat}
> /l1  --> watch triggered, getData, no exception
> /l1/l2  --> watch triggered, getData, no exception
> /l1/l2/l3  --> watch triggered, getData, no exception
> /l1/l2/l3/l4  --> watch triggered, getData, no exception
> /l1/l2/l3/l4/l5  --> watch triggered, getData, no exception
> /l1/l2/l3/l4/l5/l6  --> watch triggered, getData, NoNodeException
> {noformat}
> The only difference is that all paths up to including l5 do not actually
> have any data. Only l6 has some data. Could there be some latency issues?
> For completeness, the embedded server is started as follows.
> {code}
> // disable LOG4J JMX stuff
> System.setProperty("zookeeper.jmx.log4j.disable", Boolean.TRUE.toString());
> // get directories
> final File dataDir = new File(config.getDataLogDir());
> final File snapDir = new File(config.getDataDir());
> // clean old logs
> PurgeTxnLog.purge(dataDir, snapDir, 3);
> // create standalone server
> zkServer = new ZooKeeperServer();
> zkServer.setTxnLogFactory(new FileTxnSnapLog(dataDir, snapDir));
> zkServer.setTickTime(config.getTickTime());
> zkServer.setMinSessionTimeout(config.getMinSessionTimeout());
> zkServer.setMaxSessionTimeout(config.getMaxSessionTimeout());
> factory = new NIOServerCnxn.Factory(config.getClientPortAddress(),
> config.getMaxClientCnxns());
> // start server
> LOG.info("Starting ZooKeeper standalone server.");
> try {
>   factory.startup(zkServer);
> } catch (final InterruptedException e) {
>   LOG.warn("Interrupted during server start.", e);
>   Thread.currentThread().interrupt();
> }
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira