Build failed in Hudson: ZooKeeper-trunk #666

2010-01-15 Thread Apache Hudson Server
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/666/

--
[...truncated 119555 lines...]
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at junit.framework.TestCase.runTest(TestCase.java:168)
[junit] at junit.framework.TestCase.runBare(TestCase.java:134)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
[junit] at junit.framework.TestResult.run(TestResult.java:113)
[junit] at junit.framework.TestCase.run(TestCase.java:124)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
[junit] at junit.framework.TestSuite.run(TestSuite.java:227)
[junit] at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)
[junit] 2010-01-15 12:36:24,270 - INFO  [main:finalrequestproces...@366] - 
shutdown of request processor complete
[junit] 2010-01-15 12:36:24,270 - INFO  
[CommitProcessor:3:commitproces...@148] - CommitProcessor exited loop!
[junit] 2010-01-15 12:36:24,270 - INFO  
[FollowerRequestProcessor:3:followerrequestproces...@93] - 
FollowerRequestProcessor exited loop!
[junit] 2010-01-15 12:36:24,271 - INFO  
[SyncThread:3:syncrequestproces...@151] - SyncRequestProcessor exited!
[junit] 2010-01-15 12:36:24,271 - INFO  
[NIOServerCxn.Factory:11225:nioservercnxn$fact...@264] - NIOServerCnxn factory 
exited run method
[junit] 2010-01-15 12:36:24,271 - INFO  [main:lea...@391] - Shutdown called
[junit] java.lang.Exception: shutdown Leader! reason: quorum Peer shutdown
[junit] at 
org.apache.zookeeper.server.quorum.Leader.shutdown(Leader.java:391)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumPeer.shutdown(QuorumPeer.java:665)
[junit] at 
org.apache.zookeeper.test.ZkDatabaseCorruptionTest.testCorruption(ZkDatabaseCorruptionTest.java:128)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at junit.framework.TestCase.runTest(TestCase.java:168)
[junit] at junit.framework.TestCase.runBare(TestCase.java:134)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
[junit] at junit.framework.TestResult.run(TestResult.java:113)
[junit] at junit.framework.TestCase.run(TestCase.java:124)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
[junit] at junit.framework.TestSuite.run(TestSuite.java:227)
[junit] at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)
[junit] 2010-01-15 12:36:24,271 - INFO  [main:finalrequestproces...@366] - 
shutdown of request processor complete
[junit] 2010-01-15 12:36:24,272 - INFO  
[CommitProcessor:0:commitproces...@148] - CommitProcessor exited loop!
[junit] 2010-01-15 12:36:24,271 - INFO  
[ProcessThread:-1:preprequestproces...@119] - PrepRequestProcessor exited loop!
[junit] 2010-01-15 12:36:24,272 - INFO  
[SyncThread:0:syncrequestproces...@151] - SyncRequestProcessor exited!
[junit] 2010-01-15 12:36:24,273 - WARN  
[QuorumPeer:/0:0:0:0:0:0:0:0:11223:follo...@82] - Exception when following the 
leader
[junit] java.io.EOFException
[junit] at java.io.DataInputStream.readInt(DataInputStream.java:375)
[junit] at 
org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:66)
[junit] at 
org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:108)
[junit] at 

[jira] Updated: (ZOOKEEPER-645) Bug in WriteLock recipe implementation?

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-645:
---

  Component/s: recipes
Fix Version/s: 3.3.0
 Assignee: Jaakko Laine

Mahadev can you review this one?

 Bug in WriteLock recipe implementation?
 ---

 Key: ZOOKEEPER-645
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-645
 Project: Zookeeper
  Issue Type: Bug
  Components: recipes
Affects Versions: 3.2.2
 Environment: 3.2.2 java 1.6.0_12
Reporter: Jaakko Laine
Assignee: Jaakko Laine
Priority: Minor
 Fix For: 3.3.0

 Attachments: 645-fix-findPrefixInChildren.patch


 Not sure, but there seem to be two issues in the example WriteLock:
 (1) ZNodeName is sorted according to session ID first, and then according to 
 znode sequence number. This might cause starvation as lower session IDs 
 always get priority. WriteLock is not thread-safe in the first place, so 
 having session ID involved in compare operation does not seem to make sense.
 (2) if findPrefixInChildren finds previous ID, it should add dir in front of 
 the ID

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-645) Bug in WriteLock recipe implementation?

2010-01-15 Thread Mahadev konar (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800862#action_12800862
 ] 

Mahadev konar commented on ZOOKEEPER-645:
-

sure am doing it right now.

 Bug in WriteLock recipe implementation?
 ---

 Key: ZOOKEEPER-645
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-645
 Project: Zookeeper
  Issue Type: Bug
  Components: recipes
Affects Versions: 3.2.2
 Environment: 3.2.2 java 1.6.0_12
Reporter: Jaakko Laine
Assignee: Jaakko Laine
Priority: Minor
 Fix For: 3.3.0

 Attachments: 645-fix-findPrefixInChildren.patch


 Not sure, but there seem to be two issues in the example WriteLock:
 (1) ZNodeName is sorted according to session ID first, and then according to 
 znode sequence number. This might cause starvation as lower session IDs 
 always get priority. WriteLock is not thread-safe in the first place, so 
 having session ID involved in compare operation does not seem to make sense.
 (2) if findPrefixInChildren finds previous ID, it should add dir in front of 
 the ID

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-645) Bug in WriteLock recipe implementation?

2010-01-15 Thread Mahadev konar (JIRA)

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

Mahadev konar updated ZOOKEEPER-645:


Status: Patch Available  (was: Open)

 Bug in WriteLock recipe implementation?
 ---

 Key: ZOOKEEPER-645
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-645
 Project: Zookeeper
  Issue Type: Bug
  Components: recipes
Affects Versions: 3.2.2
 Environment: 3.2.2 java 1.6.0_12
Reporter: Jaakko Laine
Assignee: Jaakko Laine
Priority: Minor
 Fix For: 3.3.0

 Attachments: 645-fix-findPrefixInChildren.patch


 Not sure, but there seem to be two issues in the example WriteLock:
 (1) ZNodeName is sorted according to session ID first, and then according to 
 znode sequence number. This might cause starvation as lower session IDs 
 always get priority. WriteLock is not thread-safe in the first place, so 
 having session ID involved in compare operation does not seem to make sense.
 (2) if findPrefixInChildren finds previous ID, it should add dir in front of 
 the ID

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-645) Bug in WriteLock recipe implementation?

2010-01-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800888#action_12800888
 ] 

Hadoop QA commented on ZOOKEEPER-645:
-

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12430357/645-fix-findPrefixInChildren.patch
  against trunk revision 899383.

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

-1 tests included.  The patch doesn't appear to include any new or modified 
tests.
Please justify why no tests are needed for this patch.

+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 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: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/103/testReport/
Findbugs warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/103/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/103/console

This message is automatically generated.

 Bug in WriteLock recipe implementation?
 ---

 Key: ZOOKEEPER-645
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-645
 Project: Zookeeper
  Issue Type: Bug
  Components: recipes
Affects Versions: 3.2.2
 Environment: 3.2.2 java 1.6.0_12
Reporter: Jaakko Laine
Assignee: Jaakko Laine
Priority: Minor
 Fix For: 3.3.0

 Attachments: 645-fix-findPrefixInChildren.patch


 Not sure, but there seem to be two issues in the example WriteLock:
 (1) ZNodeName is sorted according to session ID first, and then according to 
 znode sequence number. This might cause starvation as lower session IDs 
 always get priority. WriteLock is not thread-safe in the first place, so 
 having session ID involved in compare operation does not seem to make sense.
 (2) if findPrefixInChildren finds previous ID, it should add dir in front of 
 the ID

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-645) Bug in WriteLock recipe implementation?

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-645:
---

Status: Open  (was: Patch Available)

We should add tests to this to verify the change.


 Bug in WriteLock recipe implementation?
 ---

 Key: ZOOKEEPER-645
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-645
 Project: Zookeeper
  Issue Type: Bug
  Components: recipes
Affects Versions: 3.2.2
 Environment: 3.2.2 java 1.6.0_12
Reporter: Jaakko Laine
Assignee: Jaakko Laine
Priority: Minor
 Fix For: 3.3.0

 Attachments: 645-fix-findPrefixInChildren.patch


 Not sure, but there seem to be two issues in the example WriteLock:
 (1) ZNodeName is sorted according to session ID first, and then according to 
 znode sequence number. This might cause starvation as lower session IDs 
 always get priority. WriteLock is not thread-safe in the first place, so 
 having session ID involved in compare operation does not seem to make sense.
 (2) if findPrefixInChildren finds previous ID, it should add dir in front of 
 the ID

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (ZOOKEEPER-646) Namespace partitioning in ZK

2010-01-15 Thread Kay Kay (JIRA)
Namespace partitioning in ZK 
-

 Key: ZOOKEEPER-646
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-646
 Project: Zookeeper
  Issue Type: New Feature
Reporter: Kay Kay


Tracking JIRA for namespace partitioning in ZK 


From the mailing list (- courtesy: Mahadev / Flavio ) , discussion during Jan 
2010 - 

Hi, Mahadev said it all, we have been thinking about it for a while, but
 haven't had time to work on it. I also don't think we have a jira open for
 it; at least I couldn't find one. But, we did put together some comments:

http://wiki.apache.org/hadoop/ZooKeeper/PartitionedZookeeper

 One of the main issues we have observed there is that partitioning will
 force us to change our consistency guarantees, which is far from ideal.
 However, some users seem to be ok with it, but I'm not sure we have
 agreement.

 In any case, please feel free to contribute or simply express your
 interests so that we can take them into account.

 Thanks,
 -Flavio


 On Jan 15, 2010, at 12:49 AM, Mahadev Konar wrote:

  Hi kay,
   the namespace partitioning in zookeeper has been on a back burner for a
  long time. There isnt any jira open on it. There had been some
  discussions
  on this but no real work. Flavio/Ben have had this on there minds for a
  while but no real work/proposal is out yet.
 
  May I know is this something you are looking for in production?
 
  Thanks
  mahadev


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (ZOOKEEPER-50) Watch event delivery rules

2010-01-15 Thread Mahadev konar (JIRA)

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

Mahadev konar resolved ZOOKEEPER-50.


   Resolution: Fixed
Fix Version/s: (was: 3.3.0)
   3.0.0

this was fixed in 3.0.0


 Watch event delivery rules
 --

 Key: ZOOKEEPER-50
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-50
 Project: Zookeeper
  Issue Type: Bug
  Components: java client
Reporter: Benjamin Reed
Assignee: Benjamin Reed
 Fix For: 3.0.0


 We need to make clear in the documentation and enforce in the code the 
 following watch event rules:
 # A watch event will be delivered once to each watcher, even if it is 
 registered multiple times. For example, if the same watch object is used for 
 getChildren(/foo, watchObj) and getData(/foo, watchObj, stat) and foo is 
 deleted, watchObj will be called once to processed the NodeDeleted event.
 # Session events will be delivered to all watchers.
 *Note: a watcher is a Watcher object in Java or a (watch function, context) 
 pair in C.*
 There is currently a bug in the Java client that causes the session 
 disconnected event to be delivered twice to the default watcher if the 
 default watcher is also used to watch a path. This violates rule 1.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (ZOOKEEPER-62) Generally improve logging to enable debuggability in the field.

2010-01-15 Thread Mahadev konar (JIRA)

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

Mahadev konar resolved ZOOKEEPER-62.


Resolution: Fixed

this has been fixed with various changes to logging starting 3.0 and the 
logging has been improved since then. specific chnages to logging should be 
filed for any fixes.

 Generally improve logging to enable debuggability in the field.
 ---

 Key: ZOOKEEPER-62
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-62
 Project: Zookeeper
  Issue Type: Improvement
  Components: c client, java client, server
Reporter: Patrick Hunt
Assignee: Flavio Paiva Junqueira
 Fix For: 3.3.0

 Attachments: zoo-log.tgz


 We need to improve our logging to enable debugging of field issues.
 Flavio, assigning to you as you are currently looking at some client/server 
 issues that could benefit from better logging. Please attach patches if you 
 see potential areas for improvement.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn

2010-01-15 Thread Mahadev konar (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800933#action_12800933
 ] 

Mahadev konar commented on ZOOKEEPER-59:


flavio, will you be updating this patch?

 Synchronized block in NIOServerCnxn
 ---

 Key: ZOOKEEPER-59
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
 Project: Zookeeper
  Issue Type: Bug
  Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-59.patch


 There are two synchronized blocks locking on different objects, and to me 
 they should be guarded by the same object. Here are the parts of the code I'm 
 talking about:
 {noformat}
 nioservercnxn.readrequ...@444
 ...
   synchronized (this) {
 outstandingRequests++;
 // check throttling
 if (zk.getInProcess()  factory.outstandingLimit) {
 disableRecv();
 // following lines should not be needed since we are 
 already
 // reading
 // } else {
 // enableRecv();
 }
 } 
 {noformat}
 {noformat}
 nioservercnxn.sendrespo...@740
 ...
  synchronized (this.factory) {
 outstandingRequests--;
 // check throttling
 if (zk.getInProcess()  factory.outstandingLimit
 || outstandingRequests  1) {
 sk.selector().wakeup();
 enableRecv();
 }
 }
 {noformat}
 I think the second one is correct, and the first synchronized block should be 
 guarded by this.factory. 
 This could be related to issue ZOOKEEPER-57, but I have no concrete 
 indication that this is the case so far.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (ZOOKEEPER-86) intermittent test failure of org.apache.zookeeper.test.AsyncTest

2010-01-15 Thread Mahadev konar (JIRA)

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

Mahadev konar resolved ZOOKEEPER-86.


Resolution: Fixed

closing this issue. this does not happen any longer.

 intermittent test failure of org.apache.zookeeper.test.AsyncTest
 

 Key: ZOOKEEPER-86
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-86
 Project: Zookeeper
  Issue Type: Bug
  Components: tests
 Environment: OS X and linux. It sometimes passes; but mostly seems to 
 fail on OS X each time
Reporter: james strachan
Assignee: james strachan
 Fix For: 3.3.0

 Attachments: patch_for_ZOOKEEPER-86.patch, 
 TEST-org.apache.zookeeper.test.AsyncTest.txt


 Will attach the test output in an attachment...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-152) Improve unit tests for leader election

2010-01-15 Thread Mahadev konar (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800940#action_12800940
 ] 

Mahadev konar commented on ZOOKEEPER-152:
-

flavio, can we get this into 3.3, adding more tests for the leader election?

 Improve unit tests for leader election
 --

 Key: ZOOKEEPER-152
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-152
 Project: Zookeeper
  Issue Type: Improvement
  Components: quorum
Reporter: Flavio Paiva Junqueira
Priority: Minor
 Fix For: 3.3.0


 There are two possible tasks here:
 1- Change the algorithm tested on QuorumTest.java;
 2- Add tests for the other supported algorithms.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-152) Improve unit tests for leader election

2010-01-15 Thread Flavio Paiva Junqueira (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800943#action_12800943
 ] 

Flavio Paiva Junqueira commented on ZOOKEEPER-152:
--

Number 1 was done in ZOOKEEPER-599. I thought we were not planning on 
supporting AuthFLE anymore, so I recommend we close this jira.

 Improve unit tests for leader election
 --

 Key: ZOOKEEPER-152
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-152
 Project: Zookeeper
  Issue Type: Improvement
  Components: quorum
Reporter: Flavio Paiva Junqueira
Priority: Minor
 Fix For: 3.3.0


 There are two possible tasks here:
 1- Change the algorithm tested on QuorumTest.java;
 2- Add tests for the other supported algorithms.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-413) two flaws need addressing in the c tests that can cause false positive failures

2010-01-15 Thread Patrick Hunt (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800944#action_12800944
 ] 

Patrick Hunt commented on ZOOKEEPER-413:


item 1) is already addressed - we start a single server for all c tests (new in 
3.3.0), the script for starting the server
now waits for the server to start (up to some max time of course).

2) is still important to fix though

 two flaws need addressing in the c tests that can cause false positive 
 failures
 ---

 Key: ZOOKEEPER-413
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-413
 Project: Zookeeper
  Issue Type: Bug
  Components: c client, tests
Reporter: Patrick Hunt
Assignee: Mahadev konar
Priority: Minor
 Fix For: 3.3.0


 1) createClient in testclient.cc (check all tests) is not correctly waiting 
 for syncconnected to the server
 2) there are some instances of while(xxx); in the test code, this could cause 
 problems, really we need to
 have some limit on the number of iterations (other than just the test, which 
 may never return false), also the
 loop should have some sort of sleep(100msec) (whatever time) in order to 
 limit cpu use.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-458) connect_index in zookeeper handle might get out of bound.

2010-01-15 Thread Mahadev konar (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800948#action_12800948
 ] 

Mahadev konar commented on ZOOKEEPER-458:
-

steve,
 sorry was out on vacation. Did you get a chacne to take a look at it? did you 
find something?

 connect_index in zookeeper handle might get out of bound.
 -

 Key: ZOOKEEPER-458
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-458
 Project: Zookeeper
  Issue Type: Bug
  Components: c client
Reporter: Mahadev konar
Assignee: Steven Cheng
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-458.patch, ZOOKEEPER-458.patch, 
 ZOOKEEPER-458.patch, ZOOKEEPER-458.patch, ZOOKEEPER-458.patch, 
 ZOOKEEPER-458.patch, ZOOKEEPER-458.patch


 connect_index in zookeeper handle might get out of bound. the zokoeeper_init 
 method checks for index == count and sets it to zero. If the index becomes 
 greater than count, then it will go out of bounds.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-520) add static/readonly client resident serverless zookeeper

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-520:
---

Fix Version/s: (was: 3.3.0)

 add static/readonly client resident serverless zookeeper
 

 Key: ZOOKEEPER-520
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-520
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client, java client
Reporter: Patrick Hunt

 Occasionally people (typically ops) has asked for the ability to start a ZK 
 client with a hardcoded, local, non cluster based session. Meaning that you 
 can bring up a particular client with a hardcoded/readonly view of the ZK 
 namespace even if the zk cluster is not available. This seems useful for a 
 few reasons:
 1) unforseen problems - a client might be brought up and partial application 
 service restored even in the face of catastrophic cluster failure
 2) testing - client could be brought up with a hardcoded configuration for 
 testing purposes. we might even be able to extend this idea over time to 
 allow simulated changes ie - simulate other clients making changes in the 
 namespace, perhaps simulate changes in the state of the cluster (testing 
 state change is often hard for users of the client interface)
 Seems like this shouldn't be too hard for us to add. The session could be 
 established with a URI for a local/remote file rather than a URI of the 
 cluster servers. The client would essentially read this file which would be a 
 simple representation of the znode namespace.
 /foo/bar abc
 /foo/bar2 def
 etc...
 In the pure client readonly case this is simple. We might also want to allow 
 writes to the namespace (essentially back this with an in memory hash) for 
 things like group membership (so that the client continues to function).
 Obv this wouldn't work in some cases, but it might work in many and would 
 allow further options for users wrt building a relable/recoverable service on 
 top of ZK.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-517) NIO factory fails to close connections when the number of file handles run out.

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-517:
---

Priority: Critical  (was: Major)

 NIO factory fails to close connections when the number of file handles run 
 out.
 ---

 Key: ZOOKEEPER-517
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-517
 Project: Zookeeper
  Issue Type: Bug
Reporter: Mahadev konar
Priority: Critical
 Fix For: 3.3.0


 The code in NIO factory is such that if we fail to accept a connection due to 
 some reasons (too many file handles maybe one of them) we do not close the 
 connections that are in CLOSE_WAIT. We need to call an explicit close on 
 these sockets and then close them. One of the solutions might be to move doIO 
 before accpet so that we can still close connection even if we cannot accept 
 connections.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-543) Tests for ZooKeeper examples

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-543:
---

Status: Patch Available  (was: Open)

 Tests for ZooKeeper examples
 

 Key: ZOOKEEPER-543
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543
 Project: Zookeeper
  Issue Type: New Feature
  Components: tests
Affects Versions: 3.3.0
Reporter: Steven Cheng
Priority: Minor
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-543.patch


 Initial attempt to create ZooKeeper tests based on the example code on the 
 website.  
 Current plan is to test features used in examples using ZooKeeper calls 
 directly.  Another approach would be to make more usable abstractions such as 
 those in src/recipes and test those.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-543) Tests for ZooKeeper examples

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-543:
---

Assignee: Steven Cheng

 Tests for ZooKeeper examples
 

 Key: ZOOKEEPER-543
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543
 Project: Zookeeper
  Issue Type: New Feature
  Components: tests
Affects Versions: 3.3.0
Reporter: Steven Cheng
Assignee: Steven Cheng
Priority: Minor
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-543.patch


 Initial attempt to create ZooKeeper tests based on the example code on the 
 website.  
 Current plan is to test features used in examples using ZooKeeper calls 
 directly.  Another approach would be to make more usable abstractions such as 
 those in src/recipes and test those.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-613) add ganglia monitoring support as contrib

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-613:
---

Fix Version/s: (was: 3.3.0)

 add ganglia monitoring support as contrib
 -

 Key: ZOOKEEPER-613
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-613
 Project: Zookeeper
  Issue Type: Improvement
  Components: contrib, scripts
Reporter: Patrick Hunt

 It would be great to add ganglia monitoring support for ZooKeeper Cluster. 
 AFAIK this means writing a ganglia plugin that knows
 how to talk to ZK servers (either JMX, or the command port via 4letterwords)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-612) Make Zookeeper C client can be compiled by gcc of early version

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-612:
---

Status: Patch Available  (was: Open)

 Make Zookeeper C client can be compiled by gcc of early version
 ---

 Key: ZOOKEEPER-612
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-612
 Project: Zookeeper
  Issue Type: Improvement
  Components: c client
Affects Versions: 3.2.1
 Environment: Linux
Reporter: Qian Ye
Assignee: Qian Ye
 Fix For: 3.3.0

 Attachments: patch, patch, ZOOKEEPER-612.patch


 The original C Client, Version 3.2.1, cannot be compiled successfully by the 
 gcc of early version, due some declaration restriction. To compile the source 
 code on the server with gcc of early version, I made some modification on the 
 original source. What's more, some extra codes are added to make the client 
 be compatible with the hosts list format: ip1:port1, ip2:port2... There is 
 often a space after this kind of comma.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-620) hudson is not reporting compiler warning correctly

2010-01-15 Thread Mahadev konar (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800955#action_12800955
 ] 

Mahadev konar commented on ZOOKEEPER-620:
-

giri, any updates on this?

 hudson is not reporting compiler warning correctly
 --

 Key: ZOOKEEPER-620
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-620
 Project: Zookeeper
  Issue Type: Bug
  Components: tests
Affects Versions: 3.3.0
Reporter: Patrick Hunt
Assignee: Giridharan Kesavan
 Fix For: 3.3.0


 http://hudson.zones.apache.org/hudson/view/ZooKeeper/job/ZooKeeper-trunk/590/warningsResult/HIGH/
 If you click on any of these links you will see that these are not compiler 
 warnings:
 http://hudson.zones.apache.org/hudson/view/ZooKeeper/job/ZooKeeper-trunk/590/warningsResult/HIGH/file.-1602148846/
 Giri can you take a look at these and resolve?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-622) Test for pending watches in send_set_watches should be moved

2010-01-15 Thread Mahadev konar (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800956#action_12800956
 ] 

Mahadev konar commented on ZOOKEEPER-622:
-

steve, any update on this? we should try to get this into 3.3.0

 Test for pending watches in send_set_watches should be moved
 

 Key: ZOOKEEPER-622
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-622
 Project: Zookeeper
  Issue Type: Bug
  Components: c client
Reporter: Steven Cheng
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-622.patch


 Valgrind found:
 {quote}
 ==2357== Conditional jump or move depends on uninitialised value(s)
 ==2357==at 0x807FDCA: check_events (zookeeper.c:1180)
 ==2357==by 0x808043A: zookeeper_process (zookeeper.c:1775)
 ==2357==by 0x806A21B: Zookeeper_close::testCloseConnected1() 
 (TestZookeeperClose.cc:161)
 ==2357==by 0x806C6BF: CppUnit::TestCallerZookeeper_close::runTest() 
 (TestCaller.h:166)
 {quote}
 zookeeper.c:1180 was the first if in send_set_watches.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (ZOOKEEPER-647) hudson failure in testLeaderShutdown

2010-01-15 Thread Patrick Hunt (JIRA)
hudson failure in testLeaderShutdown


 Key: ZOOKEEPER-647
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-647
 Project: Zookeeper
  Issue Type: Bug
  Components: server
Reporter: Patrick Hunt
Assignee: Flavio Paiva Junqueira
Priority: Critical
 Fix For: 3.3.0


http://hudson.zones.apache.org/hudson/view/ZooKeeper/job/ZooKeeper-trunk/666/testReport/org.apache.zookeeper.test/QuorumTest/testLeaderShutdown/

junit.framework.AssertionFailedError: QP failed to shutdown in 30 seconds
at org.apache.zookeeper.test.QuorumBase.shutdown(QuorumBase.java:293)
at 
org.apache.zookeeper.test.QuorumBase.shutdownServers(QuorumBase.java:281)
at org.apache.zookeeper.test.QuorumBase.tearDown(QuorumBase.java:266)
at org.apache.zookeeper.test.QuorumTest.tearDown(QuorumTest.java:55)

Flavio, can you triage this one?


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-612) Make Zookeeper C client can be compiled by gcc of early version

2010-01-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800961#action_12800961
 ] 

Hadoop QA commented on ZOOKEEPER-612:
-

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12429617/ZOOKEEPER-612.patch
  against trunk revision 899383.

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

-1 tests included.  The patch doesn't appear to include any new or modified 
tests.
Please justify why no tests are needed for this patch.

-1 patch.  The patch command could not apply the patch.

Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/37/console

This message is automatically generated.

 Make Zookeeper C client can be compiled by gcc of early version
 ---

 Key: ZOOKEEPER-612
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-612
 Project: Zookeeper
  Issue Type: Improvement
  Components: c client
Affects Versions: 3.2.1
 Environment: Linux
Reporter: Qian Ye
Assignee: Qian Ye
 Fix For: 3.3.0

 Attachments: patch, patch, ZOOKEEPER-612.patch


 The original C Client, Version 3.2.1, cannot be compiled successfully by the 
 gcc of early version, due some declaration restriction. To compile the source 
 code on the server with gcc of early version, I made some modification on the 
 original source. What's more, some extra codes are added to make the client 
 be compatible with the hosts list format: ip1:port1, ip2:port2... There is 
 often a space after this kind of comma.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-546) add diskless ensemble support

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-546:
---

Fix Version/s: (was: 3.3.0)
   3.4.0

 add diskless ensemble support
 ---

 Key: ZOOKEEPER-546
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-546
 Project: Zookeeper
  Issue Type: New Feature
  Components: server
Reporter: Patrick Hunt
 Fix For: 3.4.0


 In some cases there is no need to have the ZK data persisted to disk. For 
 example if all you are doing is group membership and leadership
 election the data is totally ephemeral, storing on disk is unnecessary. We've 
 also seen cases where any non-ephemeral data can be
 easily recovered (say configuration data that's generated/read and loaded 
 into zk) and there is less need to worry about recovery of the
 data in the case of catastrophic failure (meaning _all_ replicas are lost, 
 remember, recovery is automatic if 2n+1 servers and = n servers
 fail, even if  n fail manual recovery is still possible as long as at least 
 1 replica, or replica backup can be recovered)
 In these cases it makes sense to have a diskless zookeeper ensemble. The 
 result should be improved write performance
 an less moving parts (no disk to fail!), simplifiying ops in cases where this 
 can be applied.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-640) make build.xml more configurable to ease packaging for linux distros

2010-01-15 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-640:
---

Status: Patch Available  (was: Open)

 make build.xml more configurable to ease packaging for linux distros
 

 Key: ZOOKEEPER-640
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-640
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Affects Versions: 3.2.1, 3.2.2
Reporter: Thomas Koch
Assignee: Patrick Hunt
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-640.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 Hi,
 I started packaging Zookeeper for Debian[1][2]. Thereby I had a problem 
 excluding contrib/rest from the build without patching the upstream tarball. 
 Could you please add some properties to your build.xml that allow me to 
 (de)select contribs? In the example below I can easily override the 
 properties:
 project name=zookeepercontrib
   
   property name=contribfilesetincludes value=*/build.xml /
   property name=contribfilesetexcludes value= /
   fileset id=contribfileset 
dir=. 
includes=${contribfilesetincludes}
excludes=${contribfilesetexcludes}
/
   target name=compile
 subant target=jar
  fileset refid=contribfileset /
 /subant
   /target
 Could you please also add a line to project.classpath:
   path id=project.classpath
   fileset dir=${additional.lib.dir} includes=*.jar/
 For Debian I may not compile based on the jar files in lib but must use the 
 jars already in Debian.
 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561947
 [2] http://git.debian.org/?p=pkg-java/zookeeper.git
 Thank you!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (ZOOKEEPER-644) Nightly build failed on hudson.

2010-01-15 Thread Mahadev konar (JIRA)

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

Mahadev konar resolved ZOOKEEPER-644.
-

Resolution: Fixed

resolved. thanks pat.

 Nightly build failed on hudson.
 ---

 Key: ZOOKEEPER-644
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-644
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.0
Reporter: Mahadev konar
Assignee: Patrick Hunt
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-644.patch


 the nighthly build has been failing. 
 http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/664/. The problem 
 seems to be 
 {code}
 BUILD FAILED
 java.lang.NoClassDefFoundError: org/apache/ivy/ant/IvyMakePom$Mapping
 Total time: 15 minutes 14 seconds
 {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-640) make build.xml more configurable to ease packaging for linux distros

2010-01-15 Thread Patrick Hunt (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800962#action_12800962
 ] 

Patrick Hunt commented on ZOOKEEPER-640:


Thomas, this good for you?

 make build.xml more configurable to ease packaging for linux distros
 

 Key: ZOOKEEPER-640
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-640
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Affects Versions: 3.2.1, 3.2.2
Reporter: Thomas Koch
Assignee: Patrick Hunt
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-640.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 Hi,
 I started packaging Zookeeper for Debian[1][2]. Thereby I had a problem 
 excluding contrib/rest from the build without patching the upstream tarball. 
 Could you please add some properties to your build.xml that allow me to 
 (de)select contribs? In the example below I can easily override the 
 properties:
 project name=zookeepercontrib
   
   property name=contribfilesetincludes value=*/build.xml /
   property name=contribfilesetexcludes value= /
   fileset id=contribfileset 
dir=. 
includes=${contribfilesetincludes}
excludes=${contribfilesetexcludes}
/
   target name=compile
 subant target=jar
  fileset refid=contribfileset /
 /subant
   /target
 Could you please also add a line to project.classpath:
   path id=project.classpath
   fileset dir=${additional.lib.dir} includes=*.jar/
 For Debian I may not compile based on the jar files in lib but must use the 
 jars already in Debian.
 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561947
 [2] http://git.debian.org/?p=pkg-java/zookeeper.git
 Thank you!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-545) investigate use of realtime gc as the recommened default for server vm

2010-01-15 Thread Patrick Hunt (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800968#action_12800968
 ] 

Patrick Hunt commented on ZOOKEEPER-545:


I've had alot of luck recently using the latest 1.6.0 jvm (_17) along with 
CMS/incremental. 

Question is, what should we do, just update the docs or make changes in the 
source as well. For example  we could change
the tests to run with CMS/Incremental.


 investigate use of realtime gc as the recommened default for server vm
 --

 Key: ZOOKEEPER-545
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-545
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Patrick Hunt
Priority: Critical
 Fix For: 3.3.0


 We currently don't recommend that ppl use the realtime gc when running the 
 server, we probably should.
 Before we do so we need to verify that it works.
 We should make it the default for all our tests.
 concurrent vs g2 or whatever it's called (new in 1.6_15 or something?)
 Update all scripts to specify this option
 update documentation to include this option and add section in the dev/ops 
 docs detailing it's benefits (in particular latency effects of gc)
 Also, -server option? any benefit for us to recommend this as well?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-543) Tests for ZooKeeper examples

2010-01-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800976#action_12800976
 ] 

Hadoop QA commented on ZOOKEEPER-543:
-

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12421475/ZOOKEEPER-543.patch
  against trunk revision 899383.

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

+1 tests included.  The patch appears to include 3 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 warnings.

-1 release audit.  The applied patch generated 208 release audit warnings 
(more than the trunk's current 207 warnings).

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

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

Test results: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/104/testReport/
Release audit warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/104/artifact/trunk/patchprocess/releaseAuditDiffWarnings.txt
Findbugs warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/104/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/104/console

This message is automatically generated.

 Tests for ZooKeeper examples
 

 Key: ZOOKEEPER-543
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543
 Project: Zookeeper
  Issue Type: New Feature
  Components: tests
Affects Versions: 3.3.0
Reporter: Steven Cheng
Assignee: Steven Cheng
Priority: Minor
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-543.patch


 Initial attempt to create ZooKeeper tests based on the example code on the 
 website.  
 Current plan is to test features used in examples using ZooKeeper calls 
 directly.  Another approach would be to make more usable abstractions such as 
 those in src/recipes and test those.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-608) Receipt of ACK from observer should not be logged as ERROR

2010-01-15 Thread Henry Robinson (JIRA)

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

Henry Robinson updated ZOOKEEPER-608:
-

Attachment: ZOOKEEPER-608.patch

Patch attached - made the message debug only. 

Rationale: we don't protect against Byzantine failures, which is effectively 
what this tests for, so no point defensively logging an error (even if I made 
it only applicable to ACKs that *are* errors). Better to make it a debug so 
that developers who understand the messages can turn them on when fixing bugs.

No tests in this one - but all tests in trunk pass. 

 Receipt of ACK from observer should not be logged as ERROR
 --

 Key: ZOOKEEPER-608
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-608
 Project: Zookeeper
  Issue Type: Improvement
Affects Versions: 3.3.0
Reporter: Henry Robinson
Assignee: Henry Robinson
Priority: Critical
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-608.patch


 Observers - in general - don't send ACKs. But a couple of times they need to. 
 Currently, these are all logged as an ERROR, which is wrong. They should at 
 most be WARN (and this would probably be confusing to the user). INFO might 
 be better. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Status on upcoming ZK 3.3.0 release

2010-01-15 Thread Patrick Hunt
ZK 3.3.0 is currently slated for March 10th. You can see a JIRA level 
overview here:

https://issues.apache.org/jira/browse/ZOOKEEPER/fixforversion/12313976

Mahadev and I did an initial triage of the 3.3.0 JIRAs today. There are 
currently 77 open issues slated for inclusion in this release, vs 110 
already addressed.


What does this mean for you? If there's a JIRA assigned to you or that 
you created that's listed for 3.3.0 please review it. If you don't plan 
on working on it for 3.3.0 reschedule it (3.4.0 or later), if you do 
plan to work on it please do so (sooner == better). If you want to get 
something into 3.3.0 that's not listed for 3.3.0 please submit a patch 
asap. As the 3.3.0 deadline approaches I will continue triaging the 
issues, in particular I will start pushing out non-blocker JIRAs that 
are not actively being worked on.


Thank you,

Patrick


[jira] Updated: (ZOOKEEPER-608) Receipt of ACK from observer should not be logged as ERROR

2010-01-15 Thread Henry Robinson (JIRA)

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

Henry Robinson updated ZOOKEEPER-608:
-

Status: Patch Available  (was: Open)

 Receipt of ACK from observer should not be logged as ERROR
 --

 Key: ZOOKEEPER-608
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-608
 Project: Zookeeper
  Issue Type: Improvement
Affects Versions: 3.3.0
Reporter: Henry Robinson
Assignee: Henry Robinson
Priority: Critical
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-608.patch


 Observers - in general - don't send ACKs. But a couple of times they need to. 
 Currently, these are all logged as an ERROR, which is wrong. They should at 
 most be WARN (and this would probably be confusing to the user). INFO might 
 be better. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-640) make build.xml more configurable to ease packaging for linux distros

2010-01-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800982#action_12800982
 ] 

Hadoop QA commented on ZOOKEEPER-640:
-

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12429777/ZOOKEEPER-640.patch
  against trunk revision 899383.

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

-1 tests included.  The patch doesn't appear to include any new or modified 
tests.
Please justify why no tests are needed for this patch.

+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 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: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/38/testReport/
Findbugs warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/38/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/38/console

This message is automatically generated.

 make build.xml more configurable to ease packaging for linux distros
 

 Key: ZOOKEEPER-640
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-640
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Affects Versions: 3.2.1, 3.2.2
Reporter: Thomas Koch
Assignee: Patrick Hunt
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-640.patch

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 Hi,
 I started packaging Zookeeper for Debian[1][2]. Thereby I had a problem 
 excluding contrib/rest from the build without patching the upstream tarball. 
 Could you please add some properties to your build.xml that allow me to 
 (de)select contribs? In the example below I can easily override the 
 properties:
 project name=zookeepercontrib
   
   property name=contribfilesetincludes value=*/build.xml /
   property name=contribfilesetexcludes value= /
   fileset id=contribfileset 
dir=. 
includes=${contribfilesetincludes}
excludes=${contribfilesetexcludes}
/
   target name=compile
 subant target=jar
  fileset refid=contribfileset /
 /subant
   /target
 Could you please also add a line to project.classpath:
   path id=project.classpath
   fileset dir=${additional.lib.dir} includes=*.jar/
 For Debian I may not compile based on the jar files in lib but must use the 
 jars already in Debian.
 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561947
 [2] http://git.debian.org/?p=pkg-java/zookeeper.git
 Thank you!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Hudson build is back to normal: ZooKeeper-trunk #667

2010-01-15 Thread Apache Hudson Server
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/667/




[jira] Commented: (ZOOKEEPER-608) Receipt of ACK from observer should not be logged as ERROR

2010-01-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801016#action_12801016
 ] 

Hadoop QA commented on ZOOKEEPER-608:
-

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12430453/ZOOKEEPER-608.patch
  against trunk revision 899383.

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

-1 tests included.  The patch doesn't appear to include any new or modified 
tests.
Please justify why no tests are needed for this patch.

+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 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: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/105/testReport/
Findbugs warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/105/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/105/console

This message is automatically generated.

 Receipt of ACK from observer should not be logged as ERROR
 --

 Key: ZOOKEEPER-608
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-608
 Project: Zookeeper
  Issue Type: Improvement
Affects Versions: 3.3.0
Reporter: Henry Robinson
Assignee: Henry Robinson
Priority: Critical
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-608.patch


 Observers - in general - don't send ACKs. But a couple of times they need to. 
 Currently, these are all logged as an ERROR, which is wrong. They should at 
 most be WARN (and this would probably be confusing to the user). INFO might 
 be better. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-608) Receipt of ACK from observer should not be logged as ERROR

2010-01-15 Thread Henry Robinson (JIRA)

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

Henry Robinson updated ZOOKEEPER-608:
-

Status: Open  (was: Patch Available)

 Receipt of ACK from observer should not be logged as ERROR
 --

 Key: ZOOKEEPER-608
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-608
 Project: Zookeeper
  Issue Type: Improvement
Affects Versions: 3.3.0
Reporter: Henry Robinson
Assignee: Henry Robinson
Priority: Critical
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-608.patch


 Observers - in general - don't send ACKs. But a couple of times they need to. 
 Currently, these are all logged as an ERROR, which is wrong. They should at 
 most be WARN (and this would probably be confusing to the user). INFO might 
 be better. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-608) Receipt of ACK from observer should not be logged as ERROR

2010-01-15 Thread Henry Robinson (JIRA)

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

Henry Robinson updated ZOOKEEPER-608:
-

Status: Patch Available  (was: Open)

Surprised at this failure, not totally sure if it's related to this patch. 
Re-starting Hudson to find out, 

 Receipt of ACK from observer should not be logged as ERROR
 --

 Key: ZOOKEEPER-608
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-608
 Project: Zookeeper
  Issue Type: Improvement
Affects Versions: 3.3.0
Reporter: Henry Robinson
Assignee: Henry Robinson
Priority: Critical
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-608.patch


 Observers - in general - don't send ACKs. But a couple of times they need to. 
 Currently, these are all logged as an ERROR, which is wrong. They should at 
 most be WARN (and this would probably be confusing to the user). INFO might 
 be better. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-608) Receipt of ACK from observer should not be logged as ERROR

2010-01-15 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801093#action_12801093
 ] 

Hadoop QA commented on ZOOKEEPER-608:
-

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12430453/ZOOKEEPER-608.patch
  against trunk revision 899383.

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

-1 tests included.  The patch doesn't appear to include any new or modified 
tests.
Please justify why no tests are needed for this patch.

+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 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: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/106/testReport/
Findbugs warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/106/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/106/console

This message is automatically generated.

 Receipt of ACK from observer should not be logged as ERROR
 --

 Key: ZOOKEEPER-608
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-608
 Project: Zookeeper
  Issue Type: Improvement
Affects Versions: 3.3.0
Reporter: Henry Robinson
Assignee: Henry Robinson
Priority: Critical
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-608.patch


 Observers - in general - don't send ACKs. But a couple of times they need to. 
 Currently, these are all logged as an ERROR, which is wrong. They should at 
 most be WARN (and this would probably be confusing to the user). INFO might 
 be better. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.