Success: ZOOKEEPER-1355 PreCommit Build #1261

2012-11-13 Thread Apache Jenkins Server 
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1355
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1261/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 162358 lines...]
 [exec] BUILD SUCCESSFUL
 [exec] Total time: 0 seconds
 [exec] 
 [exec] 
 [exec] 
 [exec] 
 [exec] +1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12553464/ZOOKEEPER-1355-13-Nov-ver2.patch
 [exec]   against trunk revision 1404288.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 31 new or 
modified tests.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 1.3.9) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1261//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1261//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1261//console
 [exec] 
 [exec] This message is automatically generated.
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Adding comment to Jira.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] Comment added.
 [exec] bx9FWpkspL logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 

BUILD SUCCESSFUL
Total time: 29 minutes 39 seconds
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1355
Email was triggered for: Success
Sending email for trigger: Success



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Commented] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)

2012-11-13 Thread Hadoop QA (JIRA) 

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

Hadoop QA commented on ZOOKEEPER-1355:
--

+1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12553464/ZOOKEEPER-1355-13-Nov-ver2.patch
  against trunk revision 1404288.

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

+1 tests included.  The patch appears to include 31 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/job/PreCommit-ZOOKEEPER-Build/1261//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1261//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1261//console

This message is automatically generated.

> Add zk.updateServerList(newServerList) 
> ---
>
> Key: ZOOKEEPER-1355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: c client, java client
>Reporter: Alexander Shraer
>Assignee: Alexander Shraer
> Fix For: 3.5.0
>
> Attachments: loadbalancing-more-details.pdf, loadbalancing.pdf, 
> ZOOKEEPER-1355-10-Oct.patch, ZOOKEEPER-1355-12-Oct.patch, 
> ZOOKEEPER-1355-13-Nov.patch, ZOOKEEPER-1355-13-Nov-ver2.patch, 
> ZOOKEEPER-1355-13-Oct.patch, ZOOKEEPER-1355-6-Nov.patch, 
> ZOOKEEPER-1355-6-Nov-ver2.patch, ZOOKEEPER-1355-ver10-1.patch, 
> ZOOKEEPER-1355-ver10-2.patch, ZOOKEEPER-1355-ver10-3.patch, 
> ZOOKEEPER-1355-ver10-4.patch, ZOOKEEPER-1355-ver10-4.patch, 
> ZOOKEEPER-1355-ver10.patch, ZOOKEEPER-1355-ver11-1.patch, 
> ZOOKEEPER-1355-ver11.patch, ZOOKEEPER-1355-ver12-1.patch, 
> ZOOKEEPER-1355-ver12-2.patch, ZOOKEEPER-1355-ver12-4.patch, 
> ZOOKEEPER-1355-ver12.patch, ZOOKEEPER-1355-ver13.patch, 
> ZOOKEEPER-1355-ver14.patch, ZOOKEEPER-1355-ver2.patch, 
> ZOOKEEPER=1355-ver3.patch, ZOOKEEPER-1355-ver4.patch, 
> ZOOKEEPER-1355-ver5.patch, ZOOKEEPER-1355-ver6.patch, 
> ZOOKEEPER-1355-ver7.patch, ZOOKEEPER-1355-ver8.patch, 
> ZOOKEEPER-1355-ver9-1.patch, ZOOKEEPER-1355-ver9.patch, 
> ZOOOKEEPER-1355.patch, ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch
>
>
> When the set of servers changes, we would like to update the server list 
> stored by clients without restarting the clients.
> Moreover, assuming that the number of clients per server is the same (in 
> expectation) in the old configuration (as guaranteed by the current list 
> shuffling for example), we would like to re-balance client connections across 
> the new set of servers in a way that a) the number of clients per server is 
> the same for all servers (in expectation) and b) there is no 
> excessive/unnecessary client migration.
> It is simple to achieve (a) without (b) - just re-shuffle the new list of 
> servers at every client. But this would create unnecessary migration, which 
> we'd like to avoid.
> We propose a simple probabilistic migration scheme that achieves (a) and (b) 
> - each client locally decides whether and where to migrate when the list of 
> servers changes. The attached document describes the scheme and shows an 
> evaluation of it in Zookeeper. We also implemented re-balancing through a 
> consistent-hashing scheme and show a comparison. We derived the probabilistic 
> migration rules from a simple formula that we can also provide, if someone's 
> interested in the proof.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Review Request: Add zk.updateServerList(newServerList)

2012-11-13 Thread Alexander Shraer 

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

(Updated Nov. 14, 2012, 6:54 a.m.)


Review request for zookeeper.


Changes
---

this corresponds to ZOOKEEPER-1355-13-Nov-ver2.patch


Description
---

https://issues.apache.org/jira/browse/ZOOKEEPER-1355


Diffs (updated)
-

  /src/c/Makefile.am 1409078 
  /src/c/include/zookeeper.h 1409078 
  /src/c/src/addrvec.h PRE-CREATION 
  /src/c/src/addrvec.c PRE-CREATION 
  /src/c/src/mt_adaptor.c 1409078 
  /src/c/src/st_adaptor.c 1409078 
  /src/c/src/zk_adaptor.h 1409078 
  /src/c/src/zookeeper.c 1409078 
  /src/c/tests/TestReconfig.cc PRE-CREATION 
  /src/c/tests/TestZookeeperClose.cc 1409078 
  /src/c/tests/TestZookeeperInit.cc 1409078 
  /src/c/tests/ZKMocks.cc 1409078 
  /src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml 1409078 
  /src/java/main/org/apache/zookeeper/ZooKeeper.java 1409078 
  /src/java/main/org/apache/zookeeper/client/HostProvider.java 1409078 
  /src/java/main/org/apache/zookeeper/client/StaticHostProvider.java 1409078 
  /src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java 1409078 

Diff: https://reviews.apache.org/r/3781/diff/


Testing
---

new tests included as part of the patch


Thanks,

Alexander Shraer

[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)

2012-11-13 Thread Marshall McMullen (JIRA) 

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

Marshall McMullen updated ZOOKEEPER-1355:
-

Attachment: ZOOKEEPER-1355-13-Nov-ver2.patch

Fix compile failure after refactor based on code review.

> Add zk.updateServerList(newServerList) 
> ---
>
> Key: ZOOKEEPER-1355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: c client, java client
>Reporter: Alexander Shraer
>Assignee: Alexander Shraer
> Fix For: 3.5.0
>
> Attachments: loadbalancing-more-details.pdf, loadbalancing.pdf, 
> ZOOKEEPER-1355-10-Oct.patch, ZOOKEEPER-1355-12-Oct.patch, 
> ZOOKEEPER-1355-13-Nov.patch, ZOOKEEPER-1355-13-Nov-ver2.patch, 
> ZOOKEEPER-1355-13-Oct.patch, ZOOKEEPER-1355-6-Nov.patch, 
> ZOOKEEPER-1355-6-Nov-ver2.patch, ZOOKEEPER-1355-ver10-1.patch, 
> ZOOKEEPER-1355-ver10-2.patch, ZOOKEEPER-1355-ver10-3.patch, 
> ZOOKEEPER-1355-ver10-4.patch, ZOOKEEPER-1355-ver10-4.patch, 
> ZOOKEEPER-1355-ver10.patch, ZOOKEEPER-1355-ver11-1.patch, 
> ZOOKEEPER-1355-ver11.patch, ZOOKEEPER-1355-ver12-1.patch, 
> ZOOKEEPER-1355-ver12-2.patch, ZOOKEEPER-1355-ver12-4.patch, 
> ZOOKEEPER-1355-ver12.patch, ZOOKEEPER-1355-ver13.patch, 
> ZOOKEEPER-1355-ver14.patch, ZOOKEEPER-1355-ver2.patch, 
> ZOOKEEPER=1355-ver3.patch, ZOOKEEPER-1355-ver4.patch, 
> ZOOKEEPER-1355-ver5.patch, ZOOKEEPER-1355-ver6.patch, 
> ZOOKEEPER-1355-ver7.patch, ZOOKEEPER-1355-ver8.patch, 
> ZOOKEEPER-1355-ver9-1.patch, ZOOKEEPER-1355-ver9.patch, 
> ZOOOKEEPER-1355.patch, ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch
>
>
> When the set of servers changes, we would like to update the server list 
> stored by clients without restarting the clients.
> Moreover, assuming that the number of clients per server is the same (in 
> expectation) in the old configuration (as guaranteed by the current list 
> shuffling for example), we would like to re-balance client connections across 
> the new set of servers in a way that a) the number of clients per server is 
> the same for all servers (in expectation) and b) there is no 
> excessive/unnecessary client migration.
> It is simple to achieve (a) without (b) - just re-shuffle the new list of 
> servers at every client. But this would create unnecessary migration, which 
> we'd like to avoid.
> We propose a simple probabilistic migration scheme that achieves (a) and (b) 
> - each client locally decides whether and where to migrate when the list of 
> servers changes. The attached document describes the scheme and shows an 
> evaluation of it in Zookeeper. We also implemented re-balancing through a 
> consistent-hashing scheme and show a comparison. We derived the probabilistic 
> migration rules from a simple formula that we can also provide, if someone's 
> interested in the proof.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Failed: ZOOKEEPER-1355 PreCommit Build #1260

2012-11-13 Thread Apache Jenkins Server 
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1355
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1260/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 162201 lines...]
 [exec] 
 [exec] 
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12553459/ZOOKEEPER-1355-13-Nov.patch
 [exec]   against trunk revision 1404288.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 31 new or 
modified tests.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 1.3.9) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] -1 core tests.  The patch failed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1260//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1260//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1260//console
 [exec] 
 [exec] This message is automatically generated.
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Adding comment to Jira.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] Comment added.
 [exec] 42x347IPJs logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1568:
 exec returned: 1

Total time: 26 minutes 15 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1355
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Commented] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)

2012-11-13 Thread Hadoop QA (JIRA) 

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

Hadoop QA commented on ZOOKEEPER-1355:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12553459/ZOOKEEPER-1355-13-Nov.patch
  against trunk revision 1404288.

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

+1 tests included.  The patch appears to include 31 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 failed core unit tests.

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

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

This message is automatically generated.

> Add zk.updateServerList(newServerList) 
> ---
>
> Key: ZOOKEEPER-1355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: c client, java client
>Reporter: Alexander Shraer
>Assignee: Alexander Shraer
> Fix For: 3.5.0
>
> Attachments: loadbalancing-more-details.pdf, loadbalancing.pdf, 
> ZOOKEEPER-1355-10-Oct.patch, ZOOKEEPER-1355-12-Oct.patch, 
> ZOOKEEPER-1355-13-Nov.patch, ZOOKEEPER-1355-13-Oct.patch, 
> ZOOKEEPER-1355-6-Nov.patch, ZOOKEEPER-1355-6-Nov-ver2.patch, 
> ZOOKEEPER-1355-ver10-1.patch, ZOOKEEPER-1355-ver10-2.patch, 
> ZOOKEEPER-1355-ver10-3.patch, ZOOKEEPER-1355-ver10-4.patch, 
> ZOOKEEPER-1355-ver10-4.patch, ZOOKEEPER-1355-ver10.patch, 
> ZOOKEEPER-1355-ver11-1.patch, ZOOKEEPER-1355-ver11.patch, 
> ZOOKEEPER-1355-ver12-1.patch, ZOOKEEPER-1355-ver12-2.patch, 
> ZOOKEEPER-1355-ver12-4.patch, ZOOKEEPER-1355-ver12.patch, 
> ZOOKEEPER-1355-ver13.patch, ZOOKEEPER-1355-ver14.patch, 
> ZOOKEEPER-1355-ver2.patch, ZOOKEEPER=1355-ver3.patch, 
> ZOOKEEPER-1355-ver4.patch, ZOOKEEPER-1355-ver5.patch, 
> ZOOKEEPER-1355-ver6.patch, ZOOKEEPER-1355-ver7.patch, 
> ZOOKEEPER-1355-ver8.patch, ZOOKEEPER-1355-ver9-1.patch, 
> ZOOKEEPER-1355-ver9.patch, ZOOOKEEPER-1355.patch, ZOOOKEEPER-1355-test.patch, 
> ZOOOKEEPER-1355-ver1.patch
>
>
> When the set of servers changes, we would like to update the server list 
> stored by clients without restarting the clients.
> Moreover, assuming that the number of clients per server is the same (in 
> expectation) in the old configuration (as guaranteed by the current list 
> shuffling for example), we would like to re-balance client connections across 
> the new set of servers in a way that a) the number of clients per server is 
> the same for all servers (in expectation) and b) there is no 
> excessive/unnecessary client migration.
> It is simple to achieve (a) without (b) - just re-shuffle the new list of 
> servers at every client. But this would create unnecessary migration, which 
> we'd like to avoid.
> We propose a simple probabilistic migration scheme that achieves (a) and (b) 
> - each client locally decides whether and where to migrate when the list of 
> servers changes. The attached document describes the scheme and shows an 
> evaluation of it in Zookeeper. We also implemented re-balancing through a 
> consistent-hashing scheme and show a comparison. We derived the probabilistic 
> migration rules from a simple formula that we can also provide, if someone's 
> interested in the proof.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Review Request: Add zk.updateServerList(newServerList)

2012-11-13 Thread Alexander Shraer 

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

(Updated Nov. 14, 2012, 6:08 a.m.)


Review request for zookeeper.


Changes
---

Updated diff that addresses all in previous diff, corresponds to 
ZOOKEEPER-1355-13-Nov.patch


Description
---

https://issues.apache.org/jira/browse/ZOOKEEPER-1355


Diffs (updated)
-

  /src/c/Makefile.am 1409078 
  /src/c/include/zookeeper.h 1409078 
  /src/c/src/addrvec.h PRE-CREATION 
  /src/c/src/addrvec.c PRE-CREATION 
  /src/c/src/mt_adaptor.c 1409078 
  /src/c/src/st_adaptor.c 1409078 
  /src/c/src/zk_adaptor.h 1409078 
  /src/c/src/zookeeper.c 1409078 
  /src/c/tests/TestReconfig.cc PRE-CREATION 
  /src/c/tests/TestZookeeperClose.cc 1409078 
  /src/c/tests/TestZookeeperInit.cc 1409078 
  /src/c/tests/ZKMocks.cc 1409078 
  /src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml 1409078 
  /src/java/main/org/apache/zookeeper/ZooKeeper.java 1409078 
  /src/java/main/org/apache/zookeeper/client/HostProvider.java 1409078 
  /src/java/main/org/apache/zookeeper/client/StaticHostProvider.java 1409078 
  /src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java 1409078 

Diff: https://reviews.apache.org/r/3781/diff/


Testing
---

new tests included as part of the patch


Thanks,

Alexander Shraer

Re: Review Request: Add zk.updateServerList(newServerList)

2012-11-13 Thread Marshall McMullen 


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/include/zookeeper.h, line 492
> > 
> >
> > Its purpose...

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/src/addrvec.c, line 43
> > 
> >
> > Are these reds extra tabs? Can we remove them?

These are lines that have only whitespace. I'll remove them.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/src/addrvec.c, line 211
> > 
> >
> > Initializing i twice.

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/src/zk_adaptor.h, line 191
> > 
> >
> > Adding more red here.

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/src/zookeeper.c, line 794
> > 
> >
> > Can we use a label that indicates that this goto is due to an error?

Good suggestion. Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 37
> > 
> >
> > I couldn't figure the conventions being used for the names of methods, 
> > and I've noticed that a few method names start with capital. Can we make 
> > sure that we are complying with the conventions used for existing code?

Yep, I'll update the naming conventions.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 83
> > 
> >
> > More red...

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 75
> > 
> >
> > its random choices...

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 298
> > 
> >
> > CreateHostList -> createHostList

Fixed... as well as all the other naming conventions.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 368
> > 
> >
> > long line

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 376
> > 
> >
> > long line

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 411
> > 
> >
> > currently connected

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 539
> > 
> >
> > If I understand the test correctly, it doesn't really check if the 
> > clients have been redistributed properly. Instead, it only checks if the 
> > removed server has no client assigned to it.

Yes, that's correct.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 540
> > 
> >
> > redistributed

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 543
> > 
> >
> > redistribution

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/c/tests/TestReconfig.cc, line 547
> > 
> >
> > redistributed

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml, line 544
> > 
> >
> > A suggestion: can we break this up into multiple paragraphs and perhaps 
> > highlight the example by putting it in a separate box?

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/java/main/org/apache/zookeeper/client/StaticHostProvider.java, line 129
> > 
> >
> > This javadoc text is overflowing a bit.

Fixed.


> On Nov. 13, 2012, 5:02 p.m., fpj wrote:
> > /src/java/main/org/apache/zookeeper/client/StaticHostProvider.java, line 167
> > 
> >
> > Some red due to formatting.

Fixed.


- Marshall


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


On Nov. 6, 2012, 11:40 p.m., Alexander Shraer wrote

[jira] [Updated] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)

2012-11-13 Thread Marshall McMullen (JIRA) 

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

Marshall McMullen updated ZOOKEEPER-1355:
-

Attachment: ZOOKEEPER-1355-13-Nov.patch

Updated patch that addresses all comments in review 
https://reviews.apache.org/r/3781/

> Add zk.updateServerList(newServerList) 
> ---
>
> Key: ZOOKEEPER-1355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: c client, java client
>Reporter: Alexander Shraer
>Assignee: Alexander Shraer
> Fix For: 3.5.0
>
> Attachments: loadbalancing-more-details.pdf, loadbalancing.pdf, 
> ZOOKEEPER-1355-10-Oct.patch, ZOOKEEPER-1355-12-Oct.patch, 
> ZOOKEEPER-1355-13-Nov.patch, ZOOKEEPER-1355-13-Oct.patch, 
> ZOOKEEPER-1355-6-Nov.patch, ZOOKEEPER-1355-6-Nov-ver2.patch, 
> ZOOKEEPER-1355-ver10-1.patch, ZOOKEEPER-1355-ver10-2.patch, 
> ZOOKEEPER-1355-ver10-3.patch, ZOOKEEPER-1355-ver10-4.patch, 
> ZOOKEEPER-1355-ver10-4.patch, ZOOKEEPER-1355-ver10.patch, 
> ZOOKEEPER-1355-ver11-1.patch, ZOOKEEPER-1355-ver11.patch, 
> ZOOKEEPER-1355-ver12-1.patch, ZOOKEEPER-1355-ver12-2.patch, 
> ZOOKEEPER-1355-ver12-4.patch, ZOOKEEPER-1355-ver12.patch, 
> ZOOKEEPER-1355-ver13.patch, ZOOKEEPER-1355-ver14.patch, 
> ZOOKEEPER-1355-ver2.patch, ZOOKEEPER=1355-ver3.patch, 
> ZOOKEEPER-1355-ver4.patch, ZOOKEEPER-1355-ver5.patch, 
> ZOOKEEPER-1355-ver6.patch, ZOOKEEPER-1355-ver7.patch, 
> ZOOKEEPER-1355-ver8.patch, ZOOKEEPER-1355-ver9-1.patch, 
> ZOOKEEPER-1355-ver9.patch, ZOOOKEEPER-1355.patch, ZOOOKEEPER-1355-test.patch, 
> ZOOOKEEPER-1355-ver1.patch
>
>
> When the set of servers changes, we would like to update the server list 
> stored by clients without restarting the clients.
> Moreover, assuming that the number of clients per server is the same (in 
> expectation) in the old configuration (as guaranteed by the current list 
> shuffling for example), we would like to re-balance client connections across 
> the new set of servers in a way that a) the number of clients per server is 
> the same for all servers (in expectation) and b) there is no 
> excessive/unnecessary client migration.
> It is simple to achieve (a) without (b) - just re-shuffle the new list of 
> servers at every client. But this would create unnecessary migration, which 
> we'd like to avoid.
> We propose a simple probabilistic migration scheme that achieves (a) and (b) 
> - each client locally decides whether and where to migrate when the list of 
> servers changes. The attached document describes the scheme and shows an 
> evaluation of it in Zookeeper. We also implemented re-balancing through a 
> consistent-hashing scheme and show a comparison. We derived the probabilistic 
> migration rules from a simple formula that we can also provide, if someone's 
> interested in the proof.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1582) EndOfStreamException: Unable to read additional data from client

2012-11-13 Thread zhouyanming (JIRA) 

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

zhouyanming commented on ZOOKEEPER-1582:


same problem in Unbuntu 12.04 server 64bit

> EndOfStreamException: Unable to read additional data from client
> 
>
> Key: ZOOKEEPER-1582
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1582
> Project: ZooKeeper
>  Issue Type: Bug
> Environment: windows 7
> jdk 7
>Reporter: zhouyanming
>Priority: Blocker
>
> 1.download zookeeper-3.4.4.tar.gz and unzip
> 2.rename conf/zoo_sample.cfg to zoo.cfg
> 3.click zkServer.cmd
> 4.click zkCli.cmd
> zkCli can not connect to zkServer,it blocked
> zkServer console print
> 2012-11-13 17:28:05,302 [myid:] - WARN  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@349] - caught end of 
> stream exception
> EndOfStreamException: Unable to read additional data from client sessionid 
> 0x13af9131eee, likely client has closed socket
> at 
> org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:220)
> at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
> at java.lang.Thread.run(Thread.java:722)
> 2012-11-13 17:28:05,308 [myid:] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1001] - Closed 
> socket connection for client /127.0.0.1:54810 which had sessionid 
> 0x13af9131eee 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1582) EndOfStreamException: Unable to read additional data from client

2012-11-13 Thread zhouyanming (JIRA) 

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

zhouyanming commented on ZOOKEEPER-1582:


zkCli.cmd of version 3.3.6 can connect to zkServer.cmd of version 3.3.6
zkCli.cmd of version 3.3.6 can connect to zkServer.cmd of version 3.4.4
zkCli.cmd of version 3.4.4 can't connect to zkServer.cmd of version 3.3.6
zkCli.cmd of version 3.4.4 can't connect to zkServer.cmd of version 3.4.4

> EndOfStreamException: Unable to read additional data from client
> 
>
> Key: ZOOKEEPER-1582
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1582
> Project: ZooKeeper
>  Issue Type: Bug
> Environment: windows 7
> jdk 7
>Reporter: zhouyanming
>Priority: Blocker
>
> 1.download zookeeper-3.4.4.tar.gz and unzip
> 2.rename conf/zoo_sample.cfg to zoo.cfg
> 3.click zkServer.cmd
> 4.click zkCli.cmd
> zkCli can not connect to zkServer,it blocked
> zkServer console print
> 2012-11-13 17:28:05,302 [myid:] - WARN  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@349] - caught end of 
> stream exception
> EndOfStreamException: Unable to read additional data from client sessionid 
> 0x13af9131eee, likely client has closed socket
> at 
> org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:220)
> at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
> at java.lang.Thread.run(Thread.java:722)
> 2012-11-13 17:28:05,308 [myid:] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1001] - Closed 
> socket connection for client /127.0.0.1:54810 which had sessionid 
> 0x13af9131eee 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1546) "Unable to load database on disk" when restarting after node freeze

2012-11-13 Thread Alexander Sorokin (JIRA) 

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

Alexander Sorokin commented on ZOOKEEPER-1546:
--

We had this issue completely take down our 5-node cluster last night. After 
digging around we found that the culprit. It's a snapshot that started with 
nodes /A/B/C present. Before it got to B, both B and C got removed. So, the 
snapshot contains only /A, but the txn log starts with "delete C". When it 
replays the log, it tries to increment the cversion of the parent, which is 
/A/B. It isn't present in the snapshot and the recovery crashes.

This issue seems to have been fixed on trunk. I guess we'd just have to upgrade.

> "Unable to load database on disk" when restarting after node freeze
> ---
>
> Key: ZOOKEEPER-1546
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1546
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.3.5
>Reporter: Erik Forsberg
>
> One of my zookeeper servers in a quorum of 3 froze (probably due to 
> underlying hardware problems). When restarting, zookeeper fails to start with 
> the following in zookeeper.log:
> {noformat}
> 2012-09-04 09:02:35,300 - INFO  [main:QuorumPeerConfig@90] - Reading 
> configuration from: /etc/zookeeper/zoo.cfg
> 2012-09-04 09:02:35,316 - INFO  [main:QuorumPeerConfig@310] - Defaulting to 
> majority quorums
> 2012-09-04 09:02:35,333 - INFO  [main:QuorumPeerMain@119] - Starting quorum 
> peer
> 2012-09-04 09:02:35,358 - INFO  [main:NIOServerCnxn$Factory@143] - binding to 
> port 0.0.0.0/0.0.0.0:2181
> 2012-09-04 09:02:35,379 - INFO  [main:QuorumPeer@819] - tickTime set to 2000
> 2012-09-04 09:02:35,380 - INFO  [main:QuorumPeer@830] - minSessionTimeout set 
> to -1
> 2012-09-04 09:02:35,380 - INFO  [main:QuorumPeer@841] - maxSessionTimeout set 
> to -1
> 2012-09-04 09:02:35,386 - INFO  [main:QuorumPeer@856] - initLimit set to 10
> 2012-09-04 09:02:35,523 - INFO  [main:FileSnap@82] - Reading snapshot 
> /var/zookeeper/version-2/snapshot.500017240
> 2012-09-04 09:02:38,944 - ERROR [main:FileTxnSnapLog@226] - Failed to 
> increment parent cversion for: 
> /osp/production/scheduler/waitfordeps_tasks/per_period-3092724ef4d611e18411525400fff018-bulkload_histograms
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = 
> NoNode for 
> /osp/production/scheduler/waitfordeps_tasks/per_period-3092724ef4d611e18411525400fff018-bulkload_histograms
> at 
> org.apache.zookeeper.server.DataTree.incrementCversion(DataTree.java:1218)
> at 
> org.apache.zookeeper.server.persistence.FileTxnSnapLog.processTransaction(FileTxnSnapLog.java:224)
> at 
> org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:152)
> at 
> org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:222)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:398)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:143)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:103)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:76)
> 2012-09-04 09:02:38,945 - FATAL [main:QuorumPeer@400] - Unable to load 
> database on disk
> java.io.IOException: Failed to process transaction type: 2 error: 
> KeeperErrorCode = NoNode for 
> /osp/production/scheduler/waitfordeps_tasks/per_period-3092724ef4d611e18411525400fff018-bulkload_histograms
> at 
> org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:154)
> at 
> org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:222)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:398)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:143)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:103)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:76)
> 2012-09-04 09:02:38,946 - FATAL [main:QuorumPeerMain@87] - Unexpected 
> exception, exiting abnormally
> java.lang.RuntimeException: Unable to run quorum server 
> at 
> org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:401)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:143)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:103)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:76)
> Caused by: java.io.IOException:

Re: zookeeper_interest returning ZOK on Connection Loss

2012-11-13 Thread Yunong Xiao 
Michi -- 

On Nov 5, 2012, at 11:24 PM, Michi Mutsuzaki  wrote:

> On Mon, Nov 5, 2012 at 2:16 PM, Yunong Xiao  wrote:
>> What happens if the server is offline? In the scenario you described, 
>> select()
>> will never succeed, and zookeeper_interest() will never inform the upstream
>> consumer that the server is down. That's the crux of the problem here, when 
>> the
>> server is unavailable, the client needs to know after some amount of time 
>> that
>> the connection has failed. Otherwise the upstream consumer has no idea the
>> connection to zookeeper has been severed and will hang indefinitely.
> 
> If the server is offline, zookeeper client keeps trying to connect to
> the server indefinitely. It's up to the caller to decide when to give
> up. One possibility is to poll the connection state using zoo_state()
> and give up on the handle if it doesn't become connected after certain
> time.

I certainly don't disagree here. What you're suggesting makes sense here -- 
indeed my patch does a variation of this -- however, it relies on the consuming 
client to keep track of the time since the client was last connected to the 
server. I dare say it'd be more preferable for zookeeper.c to keep track of 
this time internally, and inform the consuming client when this time has 
exceeded a certain threshold, such as session_timeout. The consuming client can 
then decide to give up. It seems like common functionality that all consumers 
would like to have as part of using the C client.

Re: [VOTE] Release ZooKeeper 3.4.5 (candidate 1)

2012-11-13 Thread Ted Yu 
Using jdk 1.7 u9, I saw the following test failures:

Failed tests:
testRSSplitEphemeralsDisappearButDaughtersAreOnlinedAfterShutdownHandling(org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster)

testMultiRowMutationMultiThreads(org.apache.hadoop.hbase.regionserver.TestAtomicOperation):
expected:<0> but was:<1>
  queueFailover(org.apache.hadoop.hbase.replication.TestReplication):
Waited too much time for queueFailover replication. Waited 74466ms.

Tests in error:
  Broken_testSync(org.apache.hadoop.hbase.regionserver.wal.TestHLog): Error
Recovery for block blk_-3290996327764601512_1015 failed  because recovery
from primary datanode 127.0.0.1:53866 failed 6 times.  Pipeline was
127.0.0.1:53866. Aborting...
  testSplit(org.apache.hadoop.hbase.regionserver.wal.TestHLog): 3
exceptions [org.apache.hadoop.ipc.RemoteException:
org.apache.hadoop.hdfs.server.namenode.LeaseExpiredException: No lease on
/user/hduser/hbase/TestHLog/3d02052e6bcac5f74e57d2a75e6bf583/recovered.edits/004.temp
File is not open for writing. Holder DFSClient_1365323924 does not have any
open files.(..)

They passed when I ran them standalone. queueFailover has been a flaky test.

FYI

On Tue, Nov 13, 2012 at 4:15 PM, Ted Yu  wrote:

> I have run HBase trunk test suite with jdk 1.6 using zookeeper 3.4.5 RC1
> in local maven repo.
> Tests passed.
>
> Cheers
>
>
> On Tue, Nov 13, 2012 at 3:16 PM, Mahadev Konar wrote:
>
>> Anyone from hbase team wants to try it out before we close the vote?
>> Looks like Roman did some basic testing with HBase, so thats helpful.
>>
>> thanks
>> mahadev
>>
>>
>> On Mon, Nov 12, 2012 at 8:54 AM, Roman Shaposhnik  wrote:
>> > On Mon, Nov 5, 2012 at 12:20 AM, Mahadev Konar 
>> wrote:
>> >> Hi all,
>> >>
>> >>   I have created a candidate build for ZooKeeper 3.4.5. This includes
>> >> the fix for ZOOKEEPER-1560.
>> >>  Please take a look at the release notes for the jira list.
>> >>
>> >>  *** Please download, test and VOTE before the
>> >>  *** vote closes  12:00  midnight PT on Friday, Nov 9th.***
>> >>
>> >>  http://people.apache.org/~mahadev/zookeeper-3.4.5-candidate-1/
>> >>
>> >>  Should we release this?
>> >
>> > +1 (non-binding)
>> >
>> > based on Bigtop testing (HBase 0.94.2, Hadoop 2.0.2-alpha, Giraph
>> > 0.2-SNAPSHOT, Solr 4.0.0)
>> >
>> > Thanks,
>> > Roman.
>>
>
>

[jira] [Commented] (ZOOKEEPER-1295) Documentation for jute.maxbuffer is not correct in ZooKeeper Administrator's Guide

2012-11-13 Thread Dave Latham (JIRA) 

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

Dave Latham commented on ZOOKEEPER-1295:


If this value is different on client and server, is it not the case that "the 
system property must be set on all servers and clients otherwise problems will 
arise" as the document states?  I'd love to be able to change this without 
downtime to prevent occurrences of ZOOKEEPER-706 or HBASE-4246

> Documentation for jute.maxbuffer is not correct in ZooKeeper Administrator's 
> Guide
> --
>
> Key: ZOOKEEPER-1295
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1295
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.3.2
>Reporter: Daniel Lord
>  Labels: newbie
>
> The jute maxbuffer size is documented as being defaulted to 1 megabyte in the 
> administrators guide.  I believe that this is true server side but it is not 
> true client side.  On the client side the default is (at least in 3.3.2) this:
> packetLen = Integer.getInteger("jute.maxbuffer", 4096 * 1024);
> On the server side the documentation looks to be correct:
> private static int determineMaxBuffer() {
> String maxBufferString = System.getProperty("jute.maxbuffer");
> try {
> return Integer.parseInt(maxBufferString);
> } catch(Exception e) {
> return 0xf;
> }
> 
> }
> The documentation states this:
> jute.maxbuffer:
> (Java system property: jute.maxbuffer)
> This option can only be set as a Java system property. There is no zookeeper 
> prefix on it. It specifies the maximum size of the data that can be stored in 
> a znode. The default is 0xf, or just under 1M. If this option is changed, 
> the system property must be set on all servers and clients otherwise problems 
> will arise. This is really a sanity check. ZooKeeper is designed to store 
> data on the order of kilobytes in size.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release ZooKeeper 3.4.5 (candidate 1)

2012-11-13 Thread Ted Yu 
I have run HBase trunk test suite with jdk 1.6 using zookeeper 3.4.5 RC1 in
local maven repo.
Tests passed.

Cheers

On Tue, Nov 13, 2012 at 3:16 PM, Mahadev Konar wrote:

> Anyone from hbase team wants to try it out before we close the vote?
> Looks like Roman did some basic testing with HBase, so thats helpful.
>
> thanks
> mahadev
>
>
> On Mon, Nov 12, 2012 at 8:54 AM, Roman Shaposhnik  wrote:
> > On Mon, Nov 5, 2012 at 12:20 AM, Mahadev Konar 
> wrote:
> >> Hi all,
> >>
> >>   I have created a candidate build for ZooKeeper 3.4.5. This includes
> >> the fix for ZOOKEEPER-1560.
> >>  Please take a look at the release notes for the jira list.
> >>
> >>  *** Please download, test and VOTE before the
> >>  *** vote closes  12:00  midnight PT on Friday, Nov 9th.***
> >>
> >>  http://people.apache.org/~mahadev/zookeeper-3.4.5-candidate-1/
> >>
> >>  Should we release this?
> >
> > +1 (non-binding)
> >
> > based on Bigtop testing (HBase 0.94.2, Hadoop 2.0.2-alpha, Giraph
> > 0.2-SNAPSHOT, Solr 4.0.0)
> >
> > Thanks,
> > Roman.
>

Re: [VOTE] Release ZooKeeper 3.4.5 (candidate 1)

2012-11-13 Thread Mahadev Konar 
Anyone from hbase team wants to try it out before we close the vote?
Looks like Roman did some basic testing with HBase, so thats helpful.

thanks
mahadev


On Mon, Nov 12, 2012 at 8:54 AM, Roman Shaposhnik  wrote:
> On Mon, Nov 5, 2012 at 12:20 AM, Mahadev Konar  
> wrote:
>> Hi all,
>>
>>   I have created a candidate build for ZooKeeper 3.4.5. This includes
>> the fix for ZOOKEEPER-1560.
>>  Please take a look at the release notes for the jira list.
>>
>>  *** Please download, test and VOTE before the
>>  *** vote closes  12:00  midnight PT on Friday, Nov 9th.***
>>
>>  http://people.apache.org/~mahadev/zookeeper-3.4.5-candidate-1/
>>
>>  Should we release this?
>
> +1 (non-binding)
>
> based on Bigtop testing (HBase 0.94.2, Hadoop 2.0.2-alpha, Giraph
> 0.2-SNAPSHOT, Solr 4.0.0)
>
> Thanks,
> Roman.

Re: getChildren question.

2012-11-13 Thread Michi Mutsuzaki 
Hi Narasimha,

It's an opaque object. Zookeeper client doesn't do anything with it,
except that it's passed back to the callback. It's useful when you
need to pass some kind of context to the callback.

--Michi

On Tue, Nov 13, 2012 at 11:47 AM, Narasimha Tadepalli
 wrote:
> Does anybody have any idea about importance of object parameter in this below 
> method? What exactly it does if we provide some object? Documentation didn't 
> provide any details about this extra parameter. Appreciate your time.
>
>
>
> public void getChildren(String path,
>
> Watcher watcher,
>
> 
> AsyncCallback.ChildrenCallback
>  cb,
>
> Object ctx)
>
> http://zookeeper.apache.org/doc/r3.4.4/api/index.html
>
>
> for example
>
> zk.getChildren("/node/child1/subchild", watcher, childrencallback, 
> Context.MESSAGE);
>
>
> where Context is enum
>
> private enum Context {
>
> MESSAGE,
> LOCK;
> }
> NOTICE: All information in and attached to this email may be proprietary, 
> confidential, privileged and otherwise protected from improper or erroneous 
> disclosure. If you are not the sender's intended recipient, you are not 
> authorized to intercept, read, print, retain, copy, forward, or disseminate 
> this message.

[jira] [Commented] (ZOOKEEPER-1402) Upload Zookeeper package to Maven Central

2012-11-13 Thread sam rash (JIRA) 

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

sam rash commented on ZOOKEEPER-1402:
-

Hi Patrick,

I work with the zookeeper team at Facebook, with Vishal.  I've done some work 
that builds on top of the patch here that I'd like to see how you feel about.  
Mostly I've tightened up some areas of the pom, organized the directories 
according to 

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

and built a quick jute plugin to remove some of the AntRun usage.  It's sort of 
a template of how some of the AntRun could be removed (or likely some of the 
thousands+ of maven plugins can help with the remainder: version generation and 
c code building)

Should I post the two patches here?  Or would you like to skim it on a gist or 
some other form?  It's a work in progress, but we hope to use maven internally, 
and if the community agrees, hope this can help push us over to that system.

Feel free to email me at s...@fb.com as well.

Thanks.

> Upload Zookeeper package to Maven Central
> -
>
> Key: ZOOKEEPER-1402
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1402
> Project: ZooKeeper
>  Issue Type: Improvement
>Affects Versions: 3.3.4
>Reporter: Igor Lazebny
>Priority: Minor
>
> It would be great to make Zookeeper package available in Maven Central as 
> other Apache projects do (Camel, CXF, ActiveMQ, Karaf, etc).
> That would simplify usage of this package in maven builds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Review Request: Add zk.updateServerList(newServerList)

2012-11-13 Thread fpj 

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


The patch looks really good. Most of my comments are comments about the format.


/src/c/include/zookeeper.h


Its purpose...



/src/c/src/addrvec.c


Are these reds extra tabs? Can we remove them?



/src/c/src/addrvec.c


Initializing i twice.



/src/c/src/zk_adaptor.h


Adding more red here.



/src/c/src/zookeeper.c


Can we use a label that indicates that this goto is due to an error?



/src/c/tests/TestReconfig.cc


I couldn't figure the conventions being used for the names of methods, and 
I've noticed that a few method names start with capital. Can we make sure that 
we are complying with the conventions used for existing code? 



/src/c/tests/TestReconfig.cc


its random choices...



/src/c/tests/TestReconfig.cc


More red...



/src/c/tests/TestReconfig.cc


CreateHostList -> createHostList



/src/c/tests/TestReconfig.cc


long line



/src/c/tests/TestReconfig.cc


long line



/src/c/tests/TestReconfig.cc


currently connected



/src/c/tests/TestReconfig.cc


If I understand the test correctly, it doesn't really check if the clients 
have been redistributed properly. Instead, it only checks if the removed server 
has no client assigned to it.



/src/c/tests/TestReconfig.cc


redistributed



/src/c/tests/TestReconfig.cc


redistribution



/src/c/tests/TestReconfig.cc


redistributed



/src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml


A suggestion: can we break this up into multiple paragraphs and perhaps 
highlight the example by putting it in a separate box?



/src/java/main/org/apache/zookeeper/client/StaticHostProvider.java


This javadoc text is overflowing a bit.



/src/java/main/org/apache/zookeeper/client/StaticHostProvider.java


Some red due to formatting.


- fpj


On Nov. 6, 2012, 11:40 p.m., Alexander Shraer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/3781/
> ---
> 
> (Updated Nov. 6, 2012, 11:40 p.m.)
> 
> 
> Review request for zookeeper.
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/ZOOKEEPER-1355
> 
> 
> Diffs
> -
> 
>   /src/c/Makefile.am 1406178 
>   /src/c/include/zookeeper.h 1406178 
>   /src/c/src/addrvec.h PRE-CREATION 
>   /src/c/src/addrvec.c PRE-CREATION 
>   /src/c/src/mt_adaptor.c 1406178 
>   /src/c/src/st_adaptor.c 1406178 
>   /src/c/src/zk_adaptor.h 1406178 
>   /src/c/src/zookeeper.c 1406178 
>   /src/c/tests/TestReconfig.cc PRE-CREATION 
>   /src/c/tests/TestZookeeperClose.cc 1406178 
>   /src/c/tests/TestZookeeperInit.cc 1406178 
>   /src/c/tests/ZKMocks.cc 1406178 
>   /src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml 1406178 
>   /src/java/main/org/apache/zookeeper/ZooKeeper.java 1406178 
>   /src/java/main/org/apache/zookeeper/client/HostProvider.java 1406178 
>   /src/java/main/org/apache/zookeeper/client/StaticHostProvider.java 1406178 
>   /src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java 
> 1406178 
> 
> Diff: https://reviews.apache.org/r/3781/diff/
> 
> 
> Testing
> ---
> 
> new tests included as part of the patch
> 
> 
> Thanks,
> 
> Alexander Shraer
> 
>

[jira] [Created] (ZOOKEEPER-1582) EndOfStreamException: Unable to read additional data from client

2012-11-13 Thread zhouyanming (JIRA) 
zhouyanming created ZOOKEEPER-1582:
--

 Summary: EndOfStreamException: Unable to read additional data from 
client
 Key: ZOOKEEPER-1582
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1582
 Project: ZooKeeper
  Issue Type: Bug
 Environment: windows 7
jdk 7
Reporter: zhouyanming
Priority: Blocker


1.download zookeeper-3.4.4.tar.gz and unzip
2.rename conf/zoo_sample.cfg to zoo.cfg
3.click zkServer.cmd
4.click zkCli.cmd

zkCli can not connect to zkServer,it blocked
zkServer console print

2012-11-13 17:28:05,302 [myid:] - WARN  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@349] - caught end of 
stream exception
EndOfStreamException: Unable to read additional data from client sessionid 
0x13af9131eee, likely client has closed socket
at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:220)
at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
at java.lang.Thread.run(Thread.java:722)
2012-11-13 17:28:05,308 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1001] - Closed socket 
connection for client /127.0.0.1:54810 which had sessionid 0x13af9131eee 


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

ZooKeeper-trunk-solaris - Build # 381 - Failure

2012-11-13 Thread Apache Jenkins Server 
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/381/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 15 lines...]
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
at hudson.model.Run.execute(Run.java:1502)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: hudson.remoting.RequestAbortedException: 
java.io.WriteAbortedException: writing aborted; java.io.InterruptedIOException
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:724)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.io.WriteAbortedException: writing aborted; 
java.io.InterruptedIOException
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:1929)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1599)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1750)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1347)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at hudson.remoting.Command.readFrom(Command.java:90)
at 
hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
Caused by: java.io.InterruptedIOException
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at 
hudson.remoting.StandardOutputStream.write(StandardOutputStream.java:84)
at 
java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1685)
at 
java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1594)
at 
java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1173)
at 
java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1127)
at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at hudson.remoting.Command.writeTo(Command.java:81)
at 
hudson.remoting.ClassicCommandTransport.write(ClassicCommandTransport.java:41)
at hudson.remoting.Channel.send(Channel.java:497)
at hudson.remoting.Request.call(Request.java:129)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:160)
at $Proxy5.fetch2(Unknown Source)
at 
hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:122)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at 
hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:113)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
at hudson.remoting.UserRequest.perform(UserRequest.java:98)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)



###
## FAILED TESTS (if any) 
##
No te