[jira] Updated: (ZOOKEEPER-920) L7 (application layer) ping support

2010-11-09 Thread Chang Song (JIRA)

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

Chang Song updated ZOOKEEPER-920:
-

Attachment: ZOOKEEPER-920-1.patch

Added ZAPPPINGFAILED error for L7 ping error.
Fixed comments


 L7 (application layer) ping support
 ---

 Key: ZOOKEEPER-920
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-920
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client
Affects Versions: 3.3.1
Reporter: Chang Song
Assignee: Chang Song
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-920-1.patch, ZOOKEEPER-920.patch


 Zookeeper is used in applications where fault tolerance is important. Its 
 client i/o thread send/recv heartbeats to/fro Zookeeper ensemble to stay 
 connected. However healthy heartbeat does not always means that the 
 application that uses Zookeeper client is in good health, it only means that 
 ZK client thread is in good health.
 This I needed something that can tagged onto Zookeeper ping that represents 
 L7 (application) health as well.
 I have modified C client source to support this in minimal way. I am new to 
 Zookeeper, so please code review this code.  I am actually using this code in 
 our in-house solution.
 https://github.com/tru64ufs/zookeeper/commit/2196d6d5114a2fd2c0a3bc9a55f4494d47d2aece
 Thank you very much.

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



[jira] Commented: (ZOOKEEPER-921) zkPython incorrectly checks for existence of required ACL elements

2010-11-09 Thread Henry Robinson (JIRA)

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

Henry Robinson commented on ZOOKEEPER-921:
--

Nicholas - 

Good catch, thanks! Do you think you will be able to submit a patch fixing the 
args checking in check_is_acl()?

Thanks,
Henry

 zkPython incorrectly checks for existence of required ACL elements
 --

 Key: ZOOKEEPER-921
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-921
 Project: Zookeeper
  Issue Type: Bug
  Components: contrib-bindings
Affects Versions: 3.3.1, 3.4.0
 Environment: Mac OS X 10.6.4, included Python 2.6.1
Reporter: Nicholas Knight
Assignee: Nicholas Knight
 Fix For: 3.3.3, 3.4.0

 Attachments: zktest.py


 Calling {{zookeeper.create()}} seems, under certain circumstances, to be 
 corrupting a subsequent call to Python's {{logging}} module.
 Specifically, if the node does not exist (but its parent does), I end up with 
 a traceback like this when I try to make the logging call:
 {noformat}
 Traceback (most recent call last):
   File zktest.py, line 21, in module
 logger.error(Boom?)
   File 
 /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py,
  line 1046, in error
 if self.isEnabledFor(ERROR):
   File 
 /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py,
  line 1206, in isEnabledFor
 return level = self.getEffectiveLevel()
   File 
 /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/logging/__init__.py,
  line 1194, in getEffectiveLevel
 while logger:
 TypeError: an integer is required
 {noformat}
 But if the node already exists, or the parent does not exist, I get the 
 appropriate NodeExists or NoNode exceptions.
 I'll be attaching a test script that can be used to reproduce this behavior.

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



[jira] Commented: (ZOOKEEPER-920) L7 (application layer) ping support

2010-11-09 Thread Chang Song (JIRA)

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

Chang Song commented on ZOOKEEPER-920:
--

Thank you very much for your feedback, Michi.
I was wondering how do you want the unit test for C client to be done?


 L7 (application layer) ping support
 ---

 Key: ZOOKEEPER-920
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-920
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client
Affects Versions: 3.3.1
Reporter: Chang Song
Assignee: Chang Song
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-920-1.patch, ZOOKEEPER-920.patch


 Zookeeper is used in applications where fault tolerance is important. Its 
 client i/o thread send/recv heartbeats to/fro Zookeeper ensemble to stay 
 connected. However healthy heartbeat does not always means that the 
 application that uses Zookeeper client is in good health, it only means that 
 ZK client thread is in good health.
 This I needed something that can tagged onto Zookeeper ping that represents 
 L7 (application) health as well.
 I have modified C client source to support this in minimal way. I am new to 
 Zookeeper, so please code review this code.  I am actually using this code in 
 our in-house solution.
 https://github.com/tru64ufs/zookeeper/commit/2196d6d5114a2fd2c0a3bc9a55f4494d47d2aece
 Thank you very much.

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



[jira] Commented: (ZOOKEEPER-922) enable faster timeout of sessions in case of unexpected socket disconnect

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-922:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

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

Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/2//console

This message is automatically generated.

 enable faster timeout of sessions in case of unexpected socket disconnect
 -

 Key: ZOOKEEPER-922
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-922
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Camille Fournier
Assignee: Camille Fournier
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-922.patch


 In the case when a client connection is closed due to socket error instead of 
 the client calling close explicitly, it would be nice to enable the session 
 associated with that client to time out faster than the negotiated session 
 timeout. This would enable a zookeeper ensemble that is acting as a dynamic 
 discovery provider to remove ephemeral nodes for crashed clients quickly, 
 while allowing for a longer heartbeat-based timeout for java clients that 
 need to do long stop-the-world GC. 
 I propose doing this by setting the timeout associated with the crashed 
 session to minSessionTimeout.

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



[jira] Updated: (ZOOKEEPER-920) L7 (application layer) ping support

2010-11-09 Thread Chang Song (JIRA)

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

Chang Song updated ZOOKEEPER-920:
-

Attachment: (was: ZOOKEEPER-920.patch)

 L7 (application layer) ping support
 ---

 Key: ZOOKEEPER-920
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-920
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client
Affects Versions: 3.3.1
Reporter: Chang Song
Assignee: Chang Song
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-920.patch


 Zookeeper is used in applications where fault tolerance is important. Its 
 client i/o thread send/recv heartbeats to/fro Zookeeper ensemble to stay 
 connected. However healthy heartbeat does not always means that the 
 application that uses Zookeeper client is in good health, it only means that 
 ZK client thread is in good health.
 This I needed something that can tagged onto Zookeeper ping that represents 
 L7 (application) health as well.
 I have modified C client source to support this in minimal way. I am new to 
 Zookeeper, so please code review this code.  I am actually using this code in 
 our in-house solution.
 https://github.com/tru64ufs/zookeeper/commit/2196d6d5114a2fd2c0a3bc9a55f4494d47d2aece
 Thank you very much.

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



[jira] Updated: (ZOOKEEPER-920) L7 (application layer) ping support

2010-11-09 Thread Chang Song (JIRA)

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

Chang Song updated ZOOKEEPER-920:
-

Attachment: ZOOKEEPER-920.patch

I have attached a new patch.


 L7 (application layer) ping support
 ---

 Key: ZOOKEEPER-920
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-920
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client
Affects Versions: 3.3.1
Reporter: Chang Song
Assignee: Chang Song
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-920.patch


 Zookeeper is used in applications where fault tolerance is important. Its 
 client i/o thread send/recv heartbeats to/fro Zookeeper ensemble to stay 
 connected. However healthy heartbeat does not always means that the 
 application that uses Zookeeper client is in good health, it only means that 
 ZK client thread is in good health.
 This I needed something that can tagged onto Zookeeper ping that represents 
 L7 (application) health as well.
 I have modified C client source to support this in minimal way. I am new to 
 Zookeeper, so please code review this code.  I am actually using this code in 
 our in-house solution.
 https://github.com/tru64ufs/zookeeper/commit/2196d6d5114a2fd2c0a3bc9a55f4494d47d2aece
 Thank you very much.

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



[jira] Updated: (ZOOKEEPER-920) L7 (application layer) ping support

2010-11-09 Thread Chang Song (JIRA)

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

Chang Song updated ZOOKEEPER-920:
-

Attachment: (was: ZOOKEEPER-920-1.patch)

 L7 (application layer) ping support
 ---

 Key: ZOOKEEPER-920
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-920
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client
Affects Versions: 3.3.1
Reporter: Chang Song
Assignee: Chang Song
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-920.patch


 Zookeeper is used in applications where fault tolerance is important. Its 
 client i/o thread send/recv heartbeats to/fro Zookeeper ensemble to stay 
 connected. However healthy heartbeat does not always means that the 
 application that uses Zookeeper client is in good health, it only means that 
 ZK client thread is in good health.
 This I needed something that can tagged onto Zookeeper ping that represents 
 L7 (application) health as well.
 I have modified C client source to support this in minimal way. I am new to 
 Zookeeper, so please code review this code.  I am actually using this code in 
 our in-house solution.
 https://github.com/tru64ufs/zookeeper/commit/2196d6d5114a2fd2c0a3bc9a55f4494d47d2aece
 Thank you very much.

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



[jira] Commented: (ZOOKEEPER-905) enhance zkServer.sh for easier zookeeper automation-izing

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-905:
-

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12457610/zkServer.sh.diff
  against trunk revision 1032885.

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

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

Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/3//console

This message is automatically generated.

 enhance zkServer.sh for easier zookeeper automation-izing
 -

 Key: ZOOKEEPER-905
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-905
 Project: Zookeeper
  Issue Type: Improvement
  Components: scripts
Reporter: Nicholas Harteau
Assignee: Nicholas Harteau
Priority: Minor
 Fix For: 3.4.0

 Attachments: zkServer.sh.diff


 zkServer.sh is good at starting zookeeper and figuring out the right options 
 to pass along.
 unfortunately if you want to wrap zookeeper startup/shutdown in any 
 significant way, you have to reimplement a bunch of the logic there.
 the attached patch addresses a couple simple issues:
 1. add a 'start-foreground' option to zkServer.sh - this allows things that 
 expect to manage a foregrounded process (daemontools, launchd, etc) to use 
 zkServer.sh instead of rolling their own to launch zookeeper
 2. add a 'print-cmd' option to zkServer.sh - rather than launching zookeeper 
 from the script, just give me the command you'd normally use to exec 
 zookeeper.  I found this useful when writing automation to start/stop 
 zookeeper as part of smoke testing zookeeper-based applications
 3. Deal more gracefully with supplying alternate configuration files to 
 zookeeper - currently the script assumes all config files reside in 
 $ZOOCFGDIR - also useful for smoke testing
 4. communicate extra info (JMX enabled) about zookeeper on STDERR rather 
 than STDOUT (necessary for #2)
 5. fixes an issue on macos where readlink doesn't have the '-f' option.

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



[jira] Commented: (ZOOKEEPER-909) Extract NIO specific code from ClientCnxn

2010-11-09 Thread Thomas Koch (JIRA)

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

Thomas Koch commented on ZOOKEEPER-909:
---

3 out of 3 test runs did pass (as expected :-).

 Extract NIO specific code from ClientCnxn
 -

 Key: ZOOKEEPER-909
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-909
 Project: Zookeeper
  Issue Type: Sub-task
  Components: java client
Reporter: Thomas Koch
Assignee: Thomas Koch
 Fix For: 3.4.0

 Attachments: ClientCnxnSocketNetty.java, ZOOKEEPER-909.patch, 
 ZOOKEEPER-909.patch, ZOOKEEPER-909.patch, ZOOKEEPER-909.patch


 This patch is mostly the same patch as my last one for ZOOKEEPER-823 minus 
 everything Netty related. This means this patch only extract all NIO specific 
 code in the class ClientCnxnSocketNIO which extends ClientCnxnSocket.
 I've redone this patch from current trunk step by step now and couldn't find 
 any logical error. I've already done a couple of successful test runs and 
 will continue to do so this night.
 It would be nice, if we could apply this patch as soon as possible to trunk. 
 This allows us to continue to work on the netty integration without blocking 
 the ClientCnxn class. Adding Netty after this patch should be only a matter 
 of adding the ClientCnxnSocketNetty class with the appropriate test cases.
 You could help me by reviewing the patch and by running it on whatever test 
 server you have available. Please send me any complete failure log you should 
 encounter to thomas at koch point ro. Thx!
 Update: Until now, I've collected 8 successful builds in a row!

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



[jira] Commented: (ZOOKEEPER-926) Fork Hadoop common's test-patch.sh and modify for Zookeeper

2010-11-09 Thread Hudson (JIRA)

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

Hudson commented on ZOOKEEPER-926:
--

Integrated in ZooKeeper-trunk #995 (See 
[https://hudson.apache.org/hudson/job/ZooKeeper-trunk/995/])
ZOOKEEPER-926. Fork Hadoop common's test-patch.sh and modify for Zookeeper. 
Updated test-patch.sh. Contributed by nigel.
ZOOKEEPER-926. Fork Hadoop common's test-patch.sh and modify for Zookeeper. 
Build commit. Contributed by nigel.
ZOOKEEPER-926. Fork Hadoop common's test-patch.sh and modify for Zookeeper. 
Initial commit. Contributed by nigel.


 Fork Hadoop common's test-patch.sh and modify for Zookeeper
 ---

 Key: ZOOKEEPER-926
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-926
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Nigel Daley
 Attachments: ZOOKEEPER-926.patch


 Zookeeper currently uses the test-patch.sh script from the Hadoop nightly 
 dir.  This is now out of date.  I propose we just copy the updated one in 
 Hadoop common and then modify for ZK.  This will also help as ZK moves out of 
 Hadoop to it's own TLP.  

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



[jira] Updated: (ZOOKEEPER-905) enhance zkServer.sh for easier zookeeper automation-izing

2010-11-09 Thread Nicholas Harteau (JIRA)

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

Nicholas Harteau updated ZOOKEEPER-905:
---

Attachment: (was: zkServer.sh.diff)

 enhance zkServer.sh for easier zookeeper automation-izing
 -

 Key: ZOOKEEPER-905
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-905
 Project: Zookeeper
  Issue Type: Improvement
  Components: scripts
Reporter: Nicholas Harteau
Assignee: Nicholas Harteau
Priority: Minor
 Fix For: 3.4.0

 Attachments: zkServer.sh.diff


 zkServer.sh is good at starting zookeeper and figuring out the right options 
 to pass along.
 unfortunately if you want to wrap zookeeper startup/shutdown in any 
 significant way, you have to reimplement a bunch of the logic there.
 the attached patch addresses a couple simple issues:
 1. add a 'start-foreground' option to zkServer.sh - this allows things that 
 expect to manage a foregrounded process (daemontools, launchd, etc) to use 
 zkServer.sh instead of rolling their own to launch zookeeper
 2. add a 'print-cmd' option to zkServer.sh - rather than launching zookeeper 
 from the script, just give me the command you'd normally use to exec 
 zookeeper.  I found this useful when writing automation to start/stop 
 zookeeper as part of smoke testing zookeeper-based applications
 3. Deal more gracefully with supplying alternate configuration files to 
 zookeeper - currently the script assumes all config files reside in 
 $ZOOCFGDIR - also useful for smoke testing
 4. communicate extra info (JMX enabled) about zookeeper on STDERR rather 
 than STDOUT (necessary for #2)
 5. fixes an issue on macos where readlink doesn't have the '-f' option.

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



[jira] Updated: (ZOOKEEPER-905) enhance zkServer.sh for easier zookeeper automation-izing

2010-11-09 Thread Nicholas Harteau (JIRA)

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

Nicholas Harteau updated ZOOKEEPER-905:
---

Attachment: zkServer.sh.diff

assume that hudson calls patch from srcroot with -p1

 enhance zkServer.sh for easier zookeeper automation-izing
 -

 Key: ZOOKEEPER-905
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-905
 Project: Zookeeper
  Issue Type: Improvement
  Components: scripts
Reporter: Nicholas Harteau
Assignee: Nicholas Harteau
Priority: Minor
 Fix For: 3.4.0

 Attachments: zkServer.sh.diff


 zkServer.sh is good at starting zookeeper and figuring out the right options 
 to pass along.
 unfortunately if you want to wrap zookeeper startup/shutdown in any 
 significant way, you have to reimplement a bunch of the logic there.
 the attached patch addresses a couple simple issues:
 1. add a 'start-foreground' option to zkServer.sh - this allows things that 
 expect to manage a foregrounded process (daemontools, launchd, etc) to use 
 zkServer.sh instead of rolling their own to launch zookeeper
 2. add a 'print-cmd' option to zkServer.sh - rather than launching zookeeper 
 from the script, just give me the command you'd normally use to exec 
 zookeeper.  I found this useful when writing automation to start/stop 
 zookeeper as part of smoke testing zookeeper-based applications
 3. Deal more gracefully with supplying alternate configuration files to 
 zookeeper - currently the script assumes all config files reside in 
 $ZOOCFGDIR - also useful for smoke testing
 4. communicate extra info (JMX enabled) about zookeeper on STDERR rather 
 than STDOUT (necessary for #2)
 5. fixes an issue on macos where readlink doesn't have the '-f' option.

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



[jira] Updated: (ZOOKEEPER-905) enhance zkServer.sh for easier zookeeper automation-izing

2010-11-09 Thread Nicholas Harteau (JIRA)

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

Nicholas Harteau updated ZOOKEEPER-905:
---

Attachment: (was: zkServer.sh.diff)

 enhance zkServer.sh for easier zookeeper automation-izing
 -

 Key: ZOOKEEPER-905
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-905
 Project: Zookeeper
  Issue Type: Improvement
  Components: scripts
Reporter: Nicholas Harteau
Assignee: Nicholas Harteau
Priority: Minor
 Fix For: 3.4.0

 Attachments: zkServer.sh.diff


 zkServer.sh is good at starting zookeeper and figuring out the right options 
 to pass along.
 unfortunately if you want to wrap zookeeper startup/shutdown in any 
 significant way, you have to reimplement a bunch of the logic there.
 the attached patch addresses a couple simple issues:
 1. add a 'start-foreground' option to zkServer.sh - this allows things that 
 expect to manage a foregrounded process (daemontools, launchd, etc) to use 
 zkServer.sh instead of rolling their own to launch zookeeper
 2. add a 'print-cmd' option to zkServer.sh - rather than launching zookeeper 
 from the script, just give me the command you'd normally use to exec 
 zookeeper.  I found this useful when writing automation to start/stop 
 zookeeper as part of smoke testing zookeeper-based applications
 3. Deal more gracefully with supplying alternate configuration files to 
 zookeeper - currently the script assumes all config files reside in 
 $ZOOCFGDIR - also useful for smoke testing
 4. communicate extra info (JMX enabled) about zookeeper on STDERR rather 
 than STDOUT (necessary for #2)
 5. fixes an issue on macos where readlink doesn't have the '-f' option.

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



[jira] Updated: (ZOOKEEPER-905) enhance zkServer.sh for easier zookeeper automation-izing

2010-11-09 Thread Nicholas Harteau (JIRA)

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

Nicholas Harteau updated ZOOKEEPER-905:
---

Attachment: zkServer.sh.diff

apparently this gets called with -p0

 enhance zkServer.sh for easier zookeeper automation-izing
 -

 Key: ZOOKEEPER-905
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-905
 Project: Zookeeper
  Issue Type: Improvement
  Components: scripts
Reporter: Nicholas Harteau
Assignee: Nicholas Harteau
Priority: Minor
 Fix For: 3.4.0

 Attachments: zkServer.sh.diff


 zkServer.sh is good at starting zookeeper and figuring out the right options 
 to pass along.
 unfortunately if you want to wrap zookeeper startup/shutdown in any 
 significant way, you have to reimplement a bunch of the logic there.
 the attached patch addresses a couple simple issues:
 1. add a 'start-foreground' option to zkServer.sh - this allows things that 
 expect to manage a foregrounded process (daemontools, launchd, etc) to use 
 zkServer.sh instead of rolling their own to launch zookeeper
 2. add a 'print-cmd' option to zkServer.sh - rather than launching zookeeper 
 from the script, just give me the command you'd normally use to exec 
 zookeeper.  I found this useful when writing automation to start/stop 
 zookeeper as part of smoke testing zookeeper-based applications
 3. Deal more gracefully with supplying alternate configuration files to 
 zookeeper - currently the script assumes all config files reside in 
 $ZOOCFGDIR - also useful for smoke testing
 4. communicate extra info (JMX enabled) about zookeeper on STDERR rather 
 than STDOUT (necessary for #2)
 5. fixes an issue on macos where readlink doesn't have the '-f' option.

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



[jira] Commented: (ZOOKEEPER-917) Leader election selected incorrect leader

2010-11-09 Thread Vishal K (JIRA)

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

Vishal K commented on ZOOKEEPER-917:


Hi Flavio,

Lets see if I understand this right. Server 2 was replaced and became the 
leader. Server 2 receives old notifications from others and accepts leadership 
even if its epoch, zxid prior to receiving any notifications was 1,0.

Server 2 accepts leadership because 0, 1 vote for 2 and we allow 2 to become 
leader based on point 1. in your comment on 07/Nov/10.

My question with regards to point 1.:
- In your example, it is OK to allow A to join the cluster and become a 
follower (so that A does not remain locked out). But is it OK for A to accept 
leadership even if it has not seen the zxid reported by others (regardless of 
the votes)? Shouldn't it reject leadership?

Am I still misunderstanding the problem?


 Leader election selected incorrect leader
 -

 Key: ZOOKEEPER-917
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-917
 Project: Zookeeper
  Issue Type: Bug
  Components: leaderElection, server
Affects Versions: 3.2.2
 Environment: Cloudera distribution of zookeeper (patched to never 
 cache DNS entries)
 Debian lenny
Reporter: Alexandre Hardy
Priority: Critical
 Fix For: 3.3.3, 3.4.0

 Attachments: zklogs-20101102144159SAST.tar.gz


 We had three nodes running zookeeper:
   * 192.168.130.10
   * 192.168.130.11
   * 192.168.130.14
 192.168.130.11 failed, and was replaced by a new node 192.168.130.13 
 (automated startup). The new node had not participated in any zookeeper 
 quorum previously. The node 192.148.130.11 was permanently removed from 
 service and could not contribute to the quorum any further (powered off).
 DNS entries were updated for the new node to allow all the zookeeper servers 
 to find the new node.
 The new node 192.168.130.13 was selected as the LEADER, despite the fact that 
 it had not seen the latest zxid.
 This particular problem has not been verified with later versions of 
 zookeeper, and no attempt has been made to reproduce this problem as yet.

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



[jira] Updated: (ZOOKEEPER-926) Fork Hadoop common's test-patch.sh and modify for Zookeeper

2010-11-09 Thread Mahadev konar (JIRA)

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

Mahadev konar updated ZOOKEEPER-926:


Fix Version/s: 3.4.0

 Fork Hadoop common's test-patch.sh and modify for Zookeeper
 ---

 Key: ZOOKEEPER-926
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-926
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Nigel Daley
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-926.patch


 Zookeeper currently uses the test-patch.sh script from the Hadoop nightly 
 dir.  This is now out of date.  I propose we just copy the updated one in 
 Hadoop common and then modify for ZK.  This will also help as ZK moves out of 
 Hadoop to it's own TLP.  

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-925:


There are a few issues:

A while back I looked at replacing forrest with python's sphinx, the conversion 
itself was pretty straightforward given there was a script that did most of the 
work. I don't see a script for forrest-confluence, perhaps we could re-purpose 
the other one I used, or just do a manual search/replace of the tags. It will 
take some work to convert the formats, but not huge given the size of our 
forrest based docs.

Another issue was that we lost the hadoop lookfeel. This was really the 
insurmountable problem when I looked at it before. However now that we are 
moving out of hadoop into our own tlp space I don't see that as an issue. 
Probably we want our own look/feel anyway.

Going to maven based site gen we just need to create the toplevel pom.xml file 
and a toplevel src/site directory that contains the content and the 
descriptor (how to generate the site, what links, etc... that's all 
configurable). We can then tell people to use both ant and mvn for the time 
being. mvn would initially just be mvn site (site/doc generation) and ant for 
all the things we do today. 


I can create a patch that does maven site generation if there's sufficient 
interest (I don't want to waste my time though if everyone's not on board). 
What do you think?



 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt

 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[jira] Commented: (ZOOKEEPER-926) Fork Hadoop common's test-patch.sh and modify for Zookeeper

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-926:


+1 Thanks Nigel  Giri!

 Fork Hadoop common's test-patch.sh and modify for Zookeeper
 ---

 Key: ZOOKEEPER-926
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-926
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Nigel Daley
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-926.patch


 Zookeeper currently uses the test-patch.sh script from the Hadoop nightly 
 dir.  This is now out of date.  I propose we just copy the updated one in 
 Hadoop common and then modify for ZK.  This will also help as ZK moves out of 
 Hadoop to it's own TLP.  

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



[jira] Assigned: (ZOOKEEPER-926) Fork Hadoop common's test-patch.sh and modify for Zookeeper

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt reassigned ZOOKEEPER-926:
--

Assignee: Nigel Daley

 Fork Hadoop common's test-patch.sh and modify for Zookeeper
 ---

 Key: ZOOKEEPER-926
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-926
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Nigel Daley
Assignee: Nigel Daley
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-926.patch


 Zookeeper currently uses the test-patch.sh script from the Hadoop nightly 
 dir.  This is now out of date.  I propose we just copy the updated one in 
 Hadoop common and then modify for ZK.  This will also help as ZK moves out of 
 Hadoop to it's own TLP.  

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



[jira] Updated: (ZOOKEEPER-922) enable faster timeout of sessions in case of unexpected socket disconnect

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-922:
---

Status: Patch Available  (was: Open)

 enable faster timeout of sessions in case of unexpected socket disconnect
 -

 Key: ZOOKEEPER-922
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-922
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Camille Fournier
Assignee: Camille Fournier
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-922.patch


 In the case when a client connection is closed due to socket error instead of 
 the client calling close explicitly, it would be nice to enable the session 
 associated with that client to time out faster than the negotiated session 
 timeout. This would enable a zookeeper ensemble that is acting as a dynamic 
 discovery provider to remove ephemeral nodes for crashed clients quickly, 
 while allowing for a longer heartbeat-based timeout for java clients that 
 need to do long stop-the-world GC. 
 I propose doing this by setting the timeout associated with the crashed 
 session to minSessionTimeout.

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



[jira] Commented: (ZOOKEEPER-905) enhance zkServer.sh for easier zookeeper automation-izing

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-905:


Hi Nicholas, actually the issue is that you need to use svn to create the diff 
(hudson doesn't like the fact that it doesn't know what .orig file is)

See this page for instructions (basically checkout svn, make change, do svn 
diff)
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute

 enhance zkServer.sh for easier zookeeper automation-izing
 -

 Key: ZOOKEEPER-905
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-905
 Project: Zookeeper
  Issue Type: Improvement
  Components: scripts
Reporter: Nicholas Harteau
Assignee: Nicholas Harteau
Priority: Minor
 Fix For: 3.4.0

 Attachments: zkServer.sh.diff


 zkServer.sh is good at starting zookeeper and figuring out the right options 
 to pass along.
 unfortunately if you want to wrap zookeeper startup/shutdown in any 
 significant way, you have to reimplement a bunch of the logic there.
 the attached patch addresses a couple simple issues:
 1. add a 'start-foreground' option to zkServer.sh - this allows things that 
 expect to manage a foregrounded process (daemontools, launchd, etc) to use 
 zkServer.sh instead of rolling their own to launch zookeeper
 2. add a 'print-cmd' option to zkServer.sh - rather than launching zookeeper 
 from the script, just give me the command you'd normally use to exec 
 zookeeper.  I found this useful when writing automation to start/stop 
 zookeeper as part of smoke testing zookeeper-based applications
 3. Deal more gracefully with supplying alternate configuration files to 
 zookeeper - currently the script assumes all config files reside in 
 $ZOOCFGDIR - also useful for smoke testing
 4. communicate extra info (JMX enabled) about zookeeper on STDERR rather 
 than STDOUT (necessary for #2)
 5. fixes an issue on macos where readlink doesn't have the '-f' option.

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



[jira] Commented: (ZOOKEEPER-922) enable faster timeout of sessions in case of unexpected socket disconnect

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-922:


Hi Camille, the patch has to be created from the top most directory (trunk) 
for hudson to apply the patch correctly, please see:
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute

(basically checkout trunk, make changes, do svn diff at the toplevel)

Thanks!

 enable faster timeout of sessions in case of unexpected socket disconnect
 -

 Key: ZOOKEEPER-922
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-922
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Camille Fournier
Assignee: Camille Fournier
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-922.patch


 In the case when a client connection is closed due to socket error instead of 
 the client calling close explicitly, it would be nice to enable the session 
 associated with that client to time out faster than the negotiated session 
 timeout. This would enable a zookeeper ensemble that is acting as a dynamic 
 discovery provider to remove ephemeral nodes for crashed clients quickly, 
 while allowing for a longer heartbeat-based timeout for java clients that 
 need to do long stop-the-world GC. 
 I propose doing this by setting the timeout associated with the crashed 
 session to minSessionTimeout.

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



[jira] Commented: (ZOOKEEPER-909) Extract NIO specific code from ClientCnxn

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-909:


Hi Thomas, thanks! One more request, can you make this a single diff? Otw the 
hudson patch queue doesn't work properly.
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute

(you probably need to svn add the new file for svn diff to pick it up)

Then cancel/submit the jira again to trigger the workflow.

Thanks!

 Extract NIO specific code from ClientCnxn
 -

 Key: ZOOKEEPER-909
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-909
 Project: Zookeeper
  Issue Type: Sub-task
  Components: java client
Reporter: Thomas Koch
Assignee: Thomas Koch
 Fix For: 3.4.0

 Attachments: ClientCnxnSocketNetty.java, ZOOKEEPER-909.patch, 
 ZOOKEEPER-909.patch, ZOOKEEPER-909.patch, ZOOKEEPER-909.patch


 This patch is mostly the same patch as my last one for ZOOKEEPER-823 minus 
 everything Netty related. This means this patch only extract all NIO specific 
 code in the class ClientCnxnSocketNIO which extends ClientCnxnSocket.
 I've redone this patch from current trunk step by step now and couldn't find 
 any logical error. I've already done a couple of successful test runs and 
 will continue to do so this night.
 It would be nice, if we could apply this patch as soon as possible to trunk. 
 This allows us to continue to work on the netty integration without blocking 
 the ClientCnxn class. Adding Netty after this patch should be only a matter 
 of adding the ClientCnxnSocketNetty class with the appropriate test cases.
 You could help me by reviewing the patch and by running it on whatever test 
 server you have available. Please send me any complete failure log you should 
 encounter to thomas at koch point ro. Thx!
 Update: Until now, I've collected 8 successful builds in a row!

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Flavio Junqueira (JIRA)

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

Flavio Junqueira commented on ZOOKEEPER-925:


I'm fine with moving to a different doc system and having our own lookfeel, 
but my main concern is having a doc generation that is relatively easy to use. 
If it is difficult to use, then contributors won't feel very motivated to write 
documentation... It would be great to get folks to stop whining when they have 
to write documentation, and stop blaming Forrest. :-)

To be fair, I must say that my experience with Forrest hasn't been great. 
Having to insert tags by hand and not being able to find descriptions for tags 
easily made it hard for me to like Forrest. The output looks good for me, 
though. 

 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt

 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Benjamin Reed (JIRA)

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

Benjamin Reed commented on ZOOKEEPER-925:
-

i'm totally interested in moving to maven site! i really really want to get 
away from forrest and make it a bit easier to write doc. can we also get away 
from checking in generated doc?

 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt

 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[jira] Commented: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-780:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

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

-1 javac.  The patch appears to cause tar ant target to fail.

-1 findbugs.  The patch appears to cause Findbugs to fail.

+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.

-1 system test framework.  The patch failed system test framework compile.

Test results: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/4//testReport/
Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/4//console

This message is automatically generated.

 zkCli.sh  generates a ArrayIndexOutOfBoundsException 
 -

 Key: ZOOKEEPER-780
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
 Project: Zookeeper
  Issue Type: Bug
  Components: scripts
Affects Versions: 3.3.1
 Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
Reporter: Miguel Correia
Assignee: Andrei Savu
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch, 
 ZOOKEEPER-780.patch


 I'm starting to play with Zookeeper so I'm still running it in standalone 
 mode. This is not a big issue, but here it goes for the records. 
 I've run zkCli.sh to run some commands in the server. I created a znode 
 /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
 include the data: an exception was generated and zkCli-sh crashed, instead of 
 just showing an error. I tried a few variations and it seems like the problem 
 is not including the data.
 A copy of the screen:
 [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
 Created /groups
 [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 3
   at 
 org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
   at 
 org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Flavio Junqueira (JIRA)

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

Flavio Junqueira commented on ZOOKEEPER-925:


I was wondering if by getting away from checking in generated docs, you mean 
that anyone should be able to come and change docs freely.

 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt

 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[jira] Commented: (ZOOKEEPER-913) Version parser fails to parse 3.3.2-dev from build.xml.

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-913:


I propose we move to support the same format as maven supports:
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html

major version.minor version.incremental version-qualifier

this is close to what we do, but allows for any qualifier after the x.y.z-


 Version parser fails to parse 3.3.2-dev from build.xml.
 -

 Key: ZOOKEEPER-913
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.1
Reporter: Anthony Urso
Assignee: Anthony Urso
Priority: Critical
 Fix For: 3.4.0

 Attachments: zk-build.patch, zk-version.patch


 Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
 parse 3.3.2-dev.
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 2-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  [java]   at java.lang.Integer.parseInt(Integer.java:481)
  [java]   at java.lang.Integer.parseInt(Integer.java:514)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 1

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Benjamin Reed (JIRA)

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

Benjamin Reed commented on ZOOKEEPER-925:
-

just to be clear. we should check in the source for the docs. i'm just saying 
that we check only check in the source for the docs, not the generated pdfs and 
web pages.

 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt

 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[Discussion] Some proposed logging (log4j) JIRAs

2010-11-09 Thread Patrick Hunt
I wanted to highlight a couple recent JIRAs that may have impact on
users (api consumers AND admins of the service) in the 3.4 timeframe.
If you want to weigh in please comment on the respective jira:

1) proposal to move to slf4j (remove/replace log4j)
https://issues.apache.org/jira/browse/ZOOKEEPER-850

from user perspective not much should change as slf4j has full support
for log4j as an engine. But I'm not fully versed on every
particular.

Note that hbase is in the process of moving
https://issues.apache.org/jira/browse/HBASE-2608 and Avro has already
moved to slf4j, not sure about some of the other hadoop ex-subs.


2) on a related note. We did a bunch of work in the 3.3 timeframe to
improve logging where the severity levels of log messages tended to be
too verbose (many items which should have been debug/trace were info).
Much of this was based on feedback we received from the hbase
community. However there are still some rough edges.

A recent JIRA
https://issues.apache.org/jira/browse/ZOOKEEPER-912
is proposing some additional changes. It would be good for
users/admins (consumers of the client api and those involved with
running the service itself) to weigh in if they have any
insights/preferences. My primary concern is that we are still able to
help users when they run into trouble - ie sufficient logging at info
level, not losing critical detail in the weeds of debug/trace level.
It's unfortunate that we only have 3 levels to play with here. FF to
weigh in.

Regards,

Patrick


[jira] Updated: (ZOOKEEPER-900) FLE implementation should be improved to use non-blocking sockets

2010-11-09 Thread Mahadev konar (JIRA)

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

Mahadev konar updated ZOOKEEPER-900:


Fix Version/s: 3.4.0

 FLE implementation should be improved to use non-blocking sockets
 -

 Key: ZOOKEEPER-900
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-900
 Project: Zookeeper
  Issue Type: Bug
Reporter: Vishal K
Assignee: Flavio Junqueira
Priority: Critical
 Fix For: 3.4.0


 From earlier email exchanges:
 1. Blocking connects and accepts:
 a) The first problem is in manager.toSend(). This invokes connectOne(), which 
 does a blocking connect. While testing, I changed the code so that 
 connectOne() starts a new thread called AsyncConnct(). AsyncConnect.run() 
 does a socketChannel.connect(). After starting AsyncConnect, connectOne 
 starts a timer. connectOne continues with normal operations if the connection 
 is established before the timer expires, otherwise, when the timer expires it 
 interrupts AsyncConnect() thread and returns. In this way, I can have an 
 upper bound on the amount of time we need to wait for connect to succeed. Of 
 course, this was a quick fix for my testing. Ideally, we should use Selector 
 to do non-blocking connects/accepts. I am planning to do that later once we 
 at least have a quick fix for the problem and consensus from others for the 
 real fix (this problem is big blocker for us). Note that it is OK to do 
 blocking IO in SenderWorker and RecvWorker threads since they block IO to the 
 respective !
 peer.
 b) The blocking IO problem is not just restricted to connectOne(), but also 
 in receiveConnection(). The Listener thread calls receiveConnection() for 
 each incoming connection request. receiveConnection does blocking IO to get 
 peer's info (s.read(msgBuffer)). Worse, it invokes connectOne() back to the 
 peer that had sent the connection request. All of this is happening from the 
 Listener. In short, if a peer fails after initiating a connection, the 
 Listener thread won't be able to accept connections from other peers, because 
 it would be stuck in read() or connetOne(). Also the code has an inherent 
 cycle. initiateConnection() and receiveConnection() will have to be very 
 carefully synchronized otherwise, we could run into deadlocks. This code is 
 going to be difficult to maintain/modify.
 Also see: https://issues.apache.org/jira/browse/ZOOKEEPER-822

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



[jira] Commented: (ZOOKEEPER-902) Fix findbug issue in trunk Malicious code vulnerability

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-902:


The patch queue now has a setting:

(10:28:53 AM) nigelcdn: There's a new file in 
src/java/test/bin/test-patch.properties in which is defined the acceptable 
number of warnings
(10:29:03 AM) nigelcdn: use it very judiciously ;-)

after this issue is fixed we should adjust that file back to 0.


 Fix findbug issue in trunk Malicious code vulnerability
 -

 Key: ZOOKEEPER-902
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-902
 Project: Zookeeper
  Issue Type: Bug
  Components: quorum, server
Affects Versions: 3.4.0
Reporter: Patrick Hunt
Priority: Minor
 Fix For: 3.4.0


 https://hudson.apache.org/hudson/view/ZooKeeper/job/ZooKeeper-trunk/970/artifact/trunk/findbugs/zookeeper-findbugs-report.html#Warnings_MALICIOUS_CODE
 Malicious code vulnerability Warnings
 Code  Warning
 MSorg.apache.zookeeper.server.quorum.LeaderElection.epochGen isn't final 
 but should be

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-925:


We prolly wouldn't generate pdfs for the web site, no one seems to do that 
anymore (although it's possible if someone would want to do it explicitly for 
some reason)

We check in the source, that's a given.

We check in the generated site/docs for a reason as well. In forrest timeframe 
it was mainly due to the fact that using forrest is a pita. ;-) In maven that's 
less of a concern. For whirr we currently don't checkin the generated, but we 
are thinking of doing so to lower the bar for new users. Doesn't really matter 
much to me, we could try not committing generated first, then see if it's an 
issue.


 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt

 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[jira] Commented: (ZOOKEEPER-900) FLE implementation should be improved to use non-blocking sockets

2010-11-09 Thread Mahadev konar (JIRA)

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

Mahadev konar commented on ZOOKEEPER-900:
-

This is definitely a good step in cleaning up QuorumCnxnManager!  I have 
updated the jira to mark it for 3.4 release. Vishal is that ok with you? Would 
you be able to provide a patch for the 3.4 release?


 FLE implementation should be improved to use non-blocking sockets
 -

 Key: ZOOKEEPER-900
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-900
 Project: Zookeeper
  Issue Type: Bug
Reporter: Vishal K
Assignee: Vishal K
Priority: Critical
 Fix For: 3.4.0


 From earlier email exchanges:
 1. Blocking connects and accepts:
 a) The first problem is in manager.toSend(). This invokes connectOne(), which 
 does a blocking connect. While testing, I changed the code so that 
 connectOne() starts a new thread called AsyncConnct(). AsyncConnect.run() 
 does a socketChannel.connect(). After starting AsyncConnect, connectOne 
 starts a timer. connectOne continues with normal operations if the connection 
 is established before the timer expires, otherwise, when the timer expires it 
 interrupts AsyncConnect() thread and returns. In this way, I can have an 
 upper bound on the amount of time we need to wait for connect to succeed. Of 
 course, this was a quick fix for my testing. Ideally, we should use Selector 
 to do non-blocking connects/accepts. I am planning to do that later once we 
 at least have a quick fix for the problem and consensus from others for the 
 real fix (this problem is big blocker for us). Note that it is OK to do 
 blocking IO in SenderWorker and RecvWorker threads since they block IO to the 
 respective !
 peer.
 b) The blocking IO problem is not just restricted to connectOne(), but also 
 in receiveConnection(). The Listener thread calls receiveConnection() for 
 each incoming connection request. receiveConnection does blocking IO to get 
 peer's info (s.read(msgBuffer)). Worse, it invokes connectOne() back to the 
 peer that had sent the connection request. All of this is happening from the 
 Listener. In short, if a peer fails after initiating a connection, the 
 Listener thread won't be able to accept connections from other peers, because 
 it would be stuck in read() or connetOne(). Also the code has an inherent 
 cycle. initiateConnection() and receiveConnection() will have to be very 
 carefully synchronized otherwise, we could run into deadlocks. This code is 
 going to be difficult to maintain/modify.
 Also see: https://issues.apache.org/jira/browse/ZOOKEEPER-822

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-925:


btw, given you just checkout the repo and literally type mvn site (maven 
handles all the dependency d/l) there's basically no reason to commit the 
generated docs.


 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt

 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



ZK's hudson patch queue being worked on

2010-11-09 Thread Patrick Hunt
Nigel and Giri are working on fixing ZK's patch queue on hudson. You
may see some spurious messages for a bit as we get things working
again.

This is the hudson process that tests new JIRA patches. When you
attach a patch to a JIRA and submit it hudson will automatically
verify the patch and comment on the jira. Here's an example:
https://issues.apache.org/jira/browse/ZOOKEEPER-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12930211#action_12930211

Once hadoopqa bot has given it's blessing (typically +1 overall but
there are some exceptions) committers generally will start their
detailed review for commit.

Given this workflow/automation important that you follow the details
on our how to contribute page, esp in regards to creating the patch:
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute

If you have any questions please do let us know.

Regards,

Patrick


[jira] Commented: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-780:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify 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 appears to introduce 1 new Findbugs warnings.

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

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

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

-1 system test framework.  The patch failed system test framework compile.

Test results: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/5//testReport/
Release audit warnings: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/5//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/5//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/5//console

This message is automatically generated.

 zkCli.sh  generates a ArrayIndexOutOfBoundsException 
 -

 Key: ZOOKEEPER-780
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
 Project: Zookeeper
  Issue Type: Bug
  Components: scripts
Affects Versions: 3.3.1
 Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
Reporter: Miguel Correia
Assignee: Andrei Savu
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch, 
 ZOOKEEPER-780.patch


 I'm starting to play with Zookeeper so I'm still running it in standalone 
 mode. This is not a big issue, but here it goes for the records. 
 I've run zkCli.sh to run some commands in the server. I created a znode 
 /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
 include the data: an exception was generated and zkCli-sh crashed, instead of 
 just showing an error. I tried a few variations and it seems like the problem 
 is not including the data.
 A copy of the screen:
 [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
 Created /groups
 [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 3
   at 
 org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
   at 
 org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

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



[jira] Commented: (ZOOKEEPER-850) Switch from log4j to slf4j

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-850:


fyi hbase's jira for similar change: HBASE-2608 (looks like this patch is 
proposing similar to 2 in hbase jira?)

 Switch from log4j to slf4j
 --

 Key: ZOOKEEPER-850
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850
 Project: Zookeeper
  Issue Type: Improvement
  Components: java client
Affects Versions: 3.3.1
Reporter: Olaf Krische
Assignee: Olaf Krische
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-3.3.1-log4j-slf4j-20101031.patch.bz2, 
 ZOOKEEPER-3.4.0-log4j-slf4j-20101102.patch.bz2


 Hello,
 i would like to see slf4j integrated into the zookeeper instead of relying 
 explicitly on log4j.
 slf4j is an abstract logging framework. There are adapters from slf4j to many 
 logger implementations, one of them is log4j.
 The decision which log engine to use i dont like to make so early.
 This would help me to embed zookeeper in my own applications (which use a 
 different logger implemenation, but slf4j is the basis)
 What do you think?
 (as i can see, those slf4j request flood all other projects on apache as well 
 :-)
 Maybe for 3.4 or 4.0?
 I can offer a patchset, i have experience in such an migration already. :-)

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



[jira] Updated: (ZOOKEEPER-850) Switch from log4j to slf4j

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-850:
---

Attachment: ZOOKEEPER-850.patch

Attaching Olaf's patch as raw patch file so that hudson can do it's magic.

 Switch from log4j to slf4j
 --

 Key: ZOOKEEPER-850
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850
 Project: Zookeeper
  Issue Type: Improvement
  Components: java client
Affects Versions: 3.3.1
Reporter: Olaf Krische
Assignee: Olaf Krische
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-3.3.1-log4j-slf4j-20101031.patch.bz2, 
 ZOOKEEPER-3.4.0-log4j-slf4j-20101102.patch.bz2, ZOOKEEPER-850.patch


 Hello,
 i would like to see slf4j integrated into the zookeeper instead of relying 
 explicitly on log4j.
 slf4j is an abstract logging framework. There are adapters from slf4j to many 
 logger implementations, one of them is log4j.
 The decision which log engine to use i dont like to make so early.
 This would help me to embed zookeeper in my own applications (which use a 
 different logger implemenation, but slf4j is the basis)
 What do you think?
 (as i can see, those slf4j request flood all other projects on apache as well 
 :-)
 Maybe for 3.4 or 4.0?
 I can offer a patchset, i have experience in such an migration already. :-)

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



[jira] Commented: (ZOOKEEPER-850) Switch from log4j to slf4j

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-850:


Olaf, re 5 could you add similar comments to this JIRA in the release notes 
section? We'll need that when doing the release itself.

 Switch from log4j to slf4j
 --

 Key: ZOOKEEPER-850
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850
 Project: Zookeeper
  Issue Type: Improvement
  Components: java client
Affects Versions: 3.3.1
Reporter: Olaf Krische
Assignee: Olaf Krische
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-3.3.1-log4j-slf4j-20101031.patch.bz2, 
 ZOOKEEPER-3.4.0-log4j-slf4j-20101102.patch.bz2, ZOOKEEPER-850.patch


 Hello,
 i would like to see slf4j integrated into the zookeeper instead of relying 
 explicitly on log4j.
 slf4j is an abstract logging framework. There are adapters from slf4j to many 
 logger implementations, one of them is log4j.
 The decision which log engine to use i dont like to make so early.
 This would help me to embed zookeeper in my own applications (which use a 
 different logger implemenation, but slf4j is the basis)
 What do you think?
 (as i can see, those slf4j request flood all other projects on apache as well 
 :-)
 Maybe for 3.4 or 4.0?
 I can offer a patchset, i have experience in such an migration already. :-)

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



[jira] Updated: (ZOOKEEPER-909) Extract NIO specific code from ClientCnxn

2010-11-09 Thread Thomas Koch (JIRA)

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

Thomas Koch updated ZOOKEEPER-909:
--

Attachment: ZOOKEEPER-909.patch

resubmitting the last patch without changes just to make hudson happy.

 Extract NIO specific code from ClientCnxn
 -

 Key: ZOOKEEPER-909
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-909
 Project: Zookeeper
  Issue Type: Sub-task
  Components: java client
Reporter: Thomas Koch
Assignee: Thomas Koch
 Fix For: 3.4.0

 Attachments: ClientCnxnSocketNetty.java, ZOOKEEPER-909.patch, 
 ZOOKEEPER-909.patch, ZOOKEEPER-909.patch, ZOOKEEPER-909.patch, 
 ZOOKEEPER-909.patch


 This patch is mostly the same patch as my last one for ZOOKEEPER-823 minus 
 everything Netty related. This means this patch only extract all NIO specific 
 code in the class ClientCnxnSocketNIO which extends ClientCnxnSocket.
 I've redone this patch from current trunk step by step now and couldn't find 
 any logical error. I've already done a couple of successful test runs and 
 will continue to do so this night.
 It would be nice, if we could apply this patch as soon as possible to trunk. 
 This allows us to continue to work on the netty integration without blocking 
 the ClientCnxn class. Adding Netty after this patch should be only a matter 
 of adding the ClientCnxnSocketNetty class with the appropriate test cases.
 You could help me by reviewing the patch and by running it on whatever test 
 server you have available. Please send me any complete failure log you should 
 encounter to thomas at koch point ro. Thx!
 Update: Until now, I've collected 8 successful builds in a row!

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



[jira] Commented: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-780:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify 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: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/6//testReport/
Findbugs warnings: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/6//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/6//console

This message is automatically generated.

 zkCli.sh  generates a ArrayIndexOutOfBoundsException 
 -

 Key: ZOOKEEPER-780
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
 Project: Zookeeper
  Issue Type: Bug
  Components: scripts
Affects Versions: 3.3.1
 Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
Reporter: Miguel Correia
Assignee: Andrei Savu
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch, 
 ZOOKEEPER-780.patch


 I'm starting to play with Zookeeper so I'm still running it in standalone 
 mode. This is not a big issue, but here it goes for the records. 
 I've run zkCli.sh to run some commands in the server. I created a znode 
 /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
 include the data: an exception was generated and zkCli-sh crashed, instead of 
 just showing an error. I tried a few variations and it seems like the problem 
 is not including the data.
 A copy of the screen:
 [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
 Created /groups
 [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 3
   at 
 org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
   at 
 org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

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



[jira] Commented: (ZOOKEEPER-922) enable faster timeout of sessions in case of unexpected socket disconnect

2010-11-09 Thread Camille Fournier (JIRA)

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

Camille Fournier commented on ZOOKEEPER-922:


I wasn't really expecting this patch to be applied by the build, since it is 
just an illustration of a possible solution for the problem (and has no unit 
tests or anything). Do you still want to run it through the build given that?

 enable faster timeout of sessions in case of unexpected socket disconnect
 -

 Key: ZOOKEEPER-922
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-922
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Camille Fournier
Assignee: Camille Fournier
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-922.patch


 In the case when a client connection is closed due to socket error instead of 
 the client calling close explicitly, it would be nice to enable the session 
 associated with that client to time out faster than the negotiated session 
 timeout. This would enable a zookeeper ensemble that is acting as a dynamic 
 discovery provider to remove ephemeral nodes for crashed clients quickly, 
 while allowing for a longer heartbeat-based timeout for java clients that 
 need to do long stop-the-world GC. 
 I propose doing this by setting the timeout associated with the crashed 
 session to minSessionTimeout.

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



[jira] Commented: (ZOOKEEPER-922) enable faster timeout of sessions in case of unexpected socket disconnect

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-922:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

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

Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/7//console

This message is automatically generated.

 enable faster timeout of sessions in case of unexpected socket disconnect
 -

 Key: ZOOKEEPER-922
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-922
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Camille Fournier
Assignee: Camille Fournier
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-922.patch


 In the case when a client connection is closed due to socket error instead of 
 the client calling close explicitly, it would be nice to enable the session 
 associated with that client to time out faster than the negotiated session 
 timeout. This would enable a zookeeper ensemble that is acting as a dynamic 
 discovery provider to remove ephemeral nodes for crashed clients quickly, 
 while allowing for a longer heartbeat-based timeout for java clients that 
 need to do long stop-the-world GC. 
 I propose doing this by setting the timeout associated with the crashed 
 session to minSessionTimeout.

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



[jira] Commented: (ZOOKEEPER-740) zkpython leading to segfault on zookeeper

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-740:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

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

Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/18//console

This message is automatically generated.

 zkpython leading to segfault on zookeeper
 -

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

 Attachments: ZOOKEEPER-740.patch


 The program that we are implementing uses the python binding for zookeeper 
 but sometimes it crash with segfault; here is the bt from gdb:
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0xad244b70 (LWP 28216)]
 0x080611d5 in PyObject_Call (func=0x862fab0, arg=0x8837194, kw=0x0)
 at ../Objects/abstract.c:2488
 2488../Objects/abstract.c: No such file or directory.
 in ../Objects/abstract.c
 (gdb) bt
 #0  0x080611d5 in PyObject_Call (func=0x862fab0, arg=0x8837194, kw=0x0)
 at ../Objects/abstract.c:2488
 #1  0x080d6ef2 in PyEval_CallObjectWithKeywords (func=0x862fab0,
 arg=0x8837194, kw=0x0) at ../Python/ceval.c:3575
 #2  0x080612a0 in PyObject_CallObject (o=0x862fab0, a=0x8837194)
 at ../Objects/abstract.c:2480
 #3  0x0047af42 in watcher_dispatch (zzh=0x86174e0, type=-1, state=1,
 path=0x86337c8 , context=0x8588660) at src/c/zookeeper.c:314
 #4  0x00496559 in do_foreach_watcher (zh=0x86174e0, type=-1, state=1,
 path=0x86337c8 , list=0xa5354140) at src/zk_hashtable.c:275
 #5  deliverWatchers (zh=0x86174e0, type=-1, state=1, path=0x86337c8 ,
 list=0xa5354140) at src/zk_hashtable.c:317
 #6  0x0048ae3c in process_completions (zh=0x86174e0) at src/zookeeper.c:1766
 #7  0x0049706b in do_completion (v=0x86174e0) at src/mt_adaptor.c:333
 #8  0x0013380e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
 #9  0x002578de in clone () from /lib/tls/i686/cmov/libc.so.6

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



[jira] Commented: (ZOOKEEPER-823) update ZooKeeper java client to optionally use Netty for connections

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-823:
-

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

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

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

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

Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/13//console

This message is automatically generated.

 update ZooKeeper java client to optionally use Netty for connections
 

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

 Attachments: NettyNettySuiteTest.rtf, 
 TEST-org.apache.zookeeper.test.NettyNettySuiteTest.txt.gz, 
 testDisconnectedAddAuth_FAILURE, testWatchAutoResetWithPending_FAILURE, 
 ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, 
 ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, 
 ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, 
 ZOOKEEPER-823.patch, ZOOKEEPER-823.patch


 This jira will port the client side connection code to use netty rather than 
 direct nio.

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



[jira] Commented: (ZOOKEEPER-877) zkpython does not work with python3.1

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-877:
-

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12456008/zookeeper.rst
  against trunk revision 1033155.

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

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

Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/10//console

This message is automatically generated.

 zkpython does not work with python3.1
 -

 Key: ZOOKEEPER-877
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-877
 Project: Zookeeper
  Issue Type: Bug
  Components: contrib-bindings
Affects Versions: 3.3.1
 Environment: linux+python3.1
Reporter: TuxRacer
Assignee: TuxRacer
 Fix For: 3.4.0

 Attachments: Doc.tgz, tests_py3k.tgz, zookeeper.c, 
 zookeeper.c.patch.v1, zookeeper.c.patch.v2, zookeeper.c.v2, zookeeper.rst


 as written in the contrib/zkpython/README file:
 Python = 2.6 is required. We have tested against 2.6. We have not tested 
 against 3.x.
 this is probably more a 'new feature' request than a bug; anyway compiling 
 the pythn module and calling it returns an error at load time:
 python3.1
 Python 3.1.2 (r312:79147, May  8 2010, 16:36:46) 
 [GCC 4.4.4] on linux2
 Type help, copyright, credits or license for more information.
  import zookeeper
 Traceback (most recent call last):
   File stdin, line 1, in module
 ImportError: /usr/local/lib/python3.1/dist-packages/zookeeper.so: undefined 
 symbol: PyString_AsString
 are there any plan to support Python3.X?
 I also tried to write a 3.1 ctypes wrapper but the C API seems in fact to be 
 written in C++, so python ctypes cannot be used.

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



[jira] Commented: (ZOOKEEPER-756) some cleanup and improvements for zooinspector

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-756:
-

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12452455/zooInspectorChanges.patch
  against trunk revision 1033155.

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

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

Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/17//console

This message is automatically generated.

 some cleanup and improvements for zooinspector
 --

 Key: ZOOKEEPER-756
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-756
 Project: Zookeeper
  Issue Type: Improvement
  Components: contrib
Affects Versions: 3.3.0
Reporter: Thomas Koch
Assignee: Colin Goodheart-Smithe
 Fix For: 3.4.0

 Attachments: zooInspectorChanges.patch


 Copied from the already closed ZOOKEEPER-678:
 * specify the exact URL, where the icons are from. It's best to include the 
 link also in the NOTICE.txt file.
 It seems, that zooinspector finds it's icons only if the icons folder is in 
 the current path. But when I install zooinspector as part of the Zookeeper 
 Debian package, I want to be able to call it regardless of the current path.
 Could you use getRessources or something so that I can point to the icons 
 location from the wrapper shell script?
 Can I place the zooinspector config files in /etc/zookeeper/zooinspector/ ? 
 Could I give zooinspector a property to point to the config file location?
 There are several places, where viewers is missspelled as Veiwers. Please 
 do a case insensitive search for veiw to correct these. Even the config 
 file defaultNodeVeiwers.cfg is missspelled like this. This has the 
 potential to confuse the hell out of people when debugging something!

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



[jira] Commented: (ZOOKEEPER-874) FileTxnSnapLog.restore does not call listener

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-874:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify 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: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/11//testReport/
Findbugs warnings: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/11//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/11//console

This message is automatically generated.

 FileTxnSnapLog.restore does not call listener
 -

 Key: ZOOKEEPER-874
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-874
 Project: Zookeeper
  Issue Type: Bug
  Components: leaderElection
Affects Versions: 3.3.1
Reporter: Diogo
Assignee: Diogo
Priority: Trivial
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-874.patch


 FileTxnSnapLog.restore() does not call listener passed as parameter. The 
 result is that the commitLogs list is empty. When a follower connects to the 
 leader, the leader is forced to send a snapshot to the follower instead of a 
 couple of requests and commits.

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



[jira] Commented: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-780:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify 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: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/15//testReport/
Findbugs warnings: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/15//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/15//console

This message is automatically generated.

 zkCli.sh  generates a ArrayIndexOutOfBoundsException 
 -

 Key: ZOOKEEPER-780
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
 Project: Zookeeper
  Issue Type: Bug
  Components: scripts
Affects Versions: 3.3.1
 Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
Reporter: Miguel Correia
Assignee: Andrei Savu
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch, 
 ZOOKEEPER-780.patch


 I'm starting to play with Zookeeper so I'm still running it in standalone 
 mode. This is not a big issue, but here it goes for the records. 
 I've run zkCli.sh to run some commands in the server. I created a znode 
 /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
 include the data: an exception was generated and zkCli-sh crashed, instead of 
 just showing an error. I tried a few variations and it seems like the problem 
 is not including the data.
 A copy of the screen:
 [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
 Created /groups
 [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 3
   at 
 org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
   at 
 org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

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



[jira] Commented: (ZOOKEEPER-906) Improve C client connection reliability by making it sleep between reconnect attempts as in Java Client

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-906:
-

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

+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 new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify 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: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/9//testReport/
Findbugs warnings: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/9//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/9//console

This message is automatically generated.

 Improve C client connection reliability by making it sleep between reconnect 
 attempts as in Java Client
 ---

 Key: ZOOKEEPER-906
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-906
 Project: Zookeeper
  Issue Type: Improvement
  Components: c client
Affects Versions: 3.3.1
Reporter: Radu Marin
Assignee: Radu Marin
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-906.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently, when a C client get disconnected, it retries a couple of hosts 
 (not all) with no delay between attempts and then if it doesn't succeed it 
 sleeps for 1/3 session expiration timeout period before trying again.
 In the worst case the disconnect event can occur after 2/3 of session 
 expiration timeout has past, and sleeping for even more 1/3 session timeout 
 will cause a session loss in most of the times.
 A better approach is to check all hosts but with random delay between 
 reconnect attempts. Also the delay must be independent of session timeout so 
 if we increase the session timeout we also increase the number of available 
 attempts.
 This improvement covers the case when the C client experiences network 
 problems for a short period of time and is not able to reach any zookeeper 
 hosts.
 Java client already uses this logic and works very good.

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



[jira] Commented: (ZOOKEEPER-850) Switch from log4j to slf4j

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-850:
-

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

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

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

This message is automatically generated.

 Switch from log4j to slf4j
 --

 Key: ZOOKEEPER-850
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850
 Project: Zookeeper
  Issue Type: Improvement
  Components: java client
Affects Versions: 3.3.1
Reporter: Olaf Krische
Assignee: Olaf Krische
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-3.3.1-log4j-slf4j-20101031.patch.bz2, 
 ZOOKEEPER-3.4.0-log4j-slf4j-20101102.patch.bz2, ZOOKEEPER-850.patch


 Hello,
 i would like to see slf4j integrated into the zookeeper instead of relying 
 explicitly on log4j.
 slf4j is an abstract logging framework. There are adapters from slf4j to many 
 logger implementations, one of them is log4j.
 The decision which log engine to use i dont like to make so early.
 This would help me to embed zookeeper in my own applications (which use a 
 different logger implemenation, but slf4j is the basis)
 What do you think?
 (as i can see, those slf4j request flood all other projects on apache as well 
 :-)
 Maybe for 3.4 or 4.0?
 I can offer a patchset, i have experience in such an migration already. :-)

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



[jira] Commented: (ZOOKEEPER-767) Submitting Demo/Recipe Shared / Exclusive Lock Code

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-767:
-

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

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

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

This message is automatically generated.

 Submitting Demo/Recipe Shared / Exclusive Lock Code
 ---

 Key: ZOOKEEPER-767
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-767
 Project: Zookeeper
  Issue Type: Improvement
  Components: recipes
Affects Versions: 3.3.0
Reporter: Sam Baskinger
Assignee: Sam Baskinger
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, 
 ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch

  Time Spent: 8h

 Networked Insights would like to share-back some code for shared/exclusive 
 locking that we are using in our labs.

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



[jira] Commented: (ZOOKEEPER-900) FLE implementation should be improved to use non-blocking sockets

2010-11-09 Thread Vishal K (JIRA)

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

Vishal K commented on ZOOKEEPER-900:


Hi Mahadev,

Yes, I will provide a patch (for the approach proposed above). I am working on 
it. I will get in touch with Flavio if I have questions.

-Vishal



 FLE implementation should be improved to use non-blocking sockets
 -

 Key: ZOOKEEPER-900
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-900
 Project: Zookeeper
  Issue Type: Bug
Reporter: Vishal K
Assignee: Vishal K
Priority: Critical
 Fix For: 3.4.0


 From earlier email exchanges:
 1. Blocking connects and accepts:
 a) The first problem is in manager.toSend(). This invokes connectOne(), which 
 does a blocking connect. While testing, I changed the code so that 
 connectOne() starts a new thread called AsyncConnct(). AsyncConnect.run() 
 does a socketChannel.connect(). After starting AsyncConnect, connectOne 
 starts a timer. connectOne continues with normal operations if the connection 
 is established before the timer expires, otherwise, when the timer expires it 
 interrupts AsyncConnect() thread and returns. In this way, I can have an 
 upper bound on the amount of time we need to wait for connect to succeed. Of 
 course, this was a quick fix for my testing. Ideally, we should use Selector 
 to do non-blocking connects/accepts. I am planning to do that later once we 
 at least have a quick fix for the problem and consensus from others for the 
 real fix (this problem is big blocker for us). Note that it is OK to do 
 blocking IO in SenderWorker and RecvWorker threads since they block IO to the 
 respective !
 peer.
 b) The blocking IO problem is not just restricted to connectOne(), but also 
 in receiveConnection(). The Listener thread calls receiveConnection() for 
 each incoming connection request. receiveConnection does blocking IO to get 
 peer's info (s.read(msgBuffer)). Worse, it invokes connectOne() back to the 
 peer that had sent the connection request. All of this is happening from the 
 Listener. In short, if a peer fails after initiating a connection, the 
 Listener thread won't be able to accept connections from other peers, because 
 it would be stuck in read() or connetOne(). Also the code has an inherent 
 cycle. initiateConnection() and receiveConnection() will have to be very 
 carefully synchronized otherwise, we could run into deadlocks. This code is 
 going to be difficult to maintain/modify.
 Also see: https://issues.apache.org/jira/browse/ZOOKEEPER-822

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



[jira] Updated: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-925:
---

Attachment: ZOOKEEPER-925.patch

apply this patch, then in the toplevel directory type mvn site:site, then 
open target/site/index.html in your browser.

Notice the index.confluence src page, try editing that (confluence wiki markup 
http://maven.apache.org/doxia/modules/index.html#Confluence) and 
regenerating/viewing the updated site. site.xml controls the layout and which 
links are put into the generated site.


 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt
 Attachments: ZOOKEEPER-925.patch


 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[jira] Assigned: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt reassigned ZOOKEEPER-925:
--

Assignee: Patrick Hunt

 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt
Assignee: Patrick Hunt
 Attachments: ZOOKEEPER-925.patch


 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[jira] Assigned: (ZOOKEEPER-913) Version parser fails to parse 3.3.2-dev from build.xml.

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt reassigned ZOOKEEPER-913:
--

Assignee: Patrick Hunt  (was: Anthony Urso)

 Version parser fails to parse 3.3.2-dev from build.xml.
 -

 Key: ZOOKEEPER-913
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.1
Reporter: Anthony Urso
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.4.0

 Attachments: zk-build.patch, zk-version.patch


 Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
 parse 3.3.2-dev.
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 2-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  [java]   at java.lang.Integer.parseInt(Integer.java:481)
  [java]   at java.lang.Integer.parseInt(Integer.java:514)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 1

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



[jira] Updated: (ZOOKEEPER-913) Version parser fails to parse 3.3.2-dev from build.xml.

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-913:
---

Fix Version/s: 3.3.3

 Version parser fails to parse 3.3.2-dev from build.xml.
 -

 Key: ZOOKEEPER-913
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.1
Reporter: Anthony Urso
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.3.3, 3.4.0

 Attachments: zk-build.patch, zk-version.patch


 Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
 parse 3.3.2-dev.
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 2-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  [java]   at java.lang.Integer.parseInt(Integer.java:481)
  [java]   at java.lang.Integer.parseInt(Integer.java:514)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 1

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



[jira] Updated: (ZOOKEEPER-913) Version parser fails to parse 3.3.2-dev from build.xml.

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-913:
---

Status: Patch Available  (was: Open)

 Version parser fails to parse 3.3.2-dev from build.xml.
 -

 Key: ZOOKEEPER-913
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.1
Reporter: Anthony Urso
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.3.3, 3.4.0

 Attachments: zk-build.patch, zk-version.patch, ZOOKEEPER-913.patch


 Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
 parse 3.3.2-dev.
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 2-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  [java]   at java.lang.Integer.parseInt(Integer.java:481)
  [java]   at java.lang.Integer.parseInt(Integer.java:514)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 1

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



[jira] Updated: (ZOOKEEPER-913) Version parser fails to parse 3.3.2-dev from build.xml.

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-913:
---

Attachment: ZOOKEEPER-913.patch

this most recent patch implements support for a version format similar to what 
maven does. 

Added tests, also verified on the command line (build) using -Dversion option. 
Seems to work ok.

 Version parser fails to parse 3.3.2-dev from build.xml.
 -

 Key: ZOOKEEPER-913
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.1
Reporter: Anthony Urso
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.3.3, 3.4.0

 Attachments: zk-build.patch, zk-version.patch, ZOOKEEPER-913.patch


 Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
 parse 3.3.2-dev.
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 2-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  [java]   at java.lang.Integer.parseInt(Integer.java:481)
  [java]   at java.lang.Integer.parseInt(Integer.java:514)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 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-891) Allow non-numeric version strings

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt resolved ZOOKEEPER-891.


Resolution: Duplicate

This is a dup of ZOOKEEPER-913  See the patch there (handles this case).

 Allow non-numeric version strings
 -

 Key: ZOOKEEPER-891
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-891
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Eli Collins
Priority: Minor
 Fix For: 3.4.0


 Non-numeric version strings (eg -dev) or -are not currently accepted, you 
 either get an error (Invalid version number format, must be x.y.z) or if 
 you pass x.y.z-dev or x.y.z+1 you'll get a NumberFormatException.  Would be 
 useful to allow non-numeric versions. 
 {noformat}
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 3-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
  [java]   at java.lang.Integer.parseInt(Integer.java:458)
  [java]   at java.lang.Integer.parseInt(Integer.java:499)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 1
 {noformat}

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



[jira] Commented: (ZOOKEEPER-913) Version parser fails to parse 3.3.2-dev from build.xml.

2010-11-09 Thread Anthony Urso (JIRA)

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

Anthony Urso commented on ZOOKEEPER-913:


Looks great, thanks!

 Version parser fails to parse 3.3.2-dev from build.xml.
 -

 Key: ZOOKEEPER-913
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.1
Reporter: Anthony Urso
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.3.3, 3.4.0

 Attachments: zk-build.patch, zk-version.patch, ZOOKEEPER-913.patch


 Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
 parse 3.3.2-dev.
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 2-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  [java]   at java.lang.Integer.parseInt(Integer.java:481)
  [java]   at java.lang.Integer.parseInt(Integer.java:514)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 1

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



[jira] Commented: (ZOOKEEPER-913) Version parser fails to parse 3.3.2-dev from build.xml.

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-913:
-

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

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

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

This message is automatically generated.

 Version parser fails to parse 3.3.2-dev from build.xml.
 -

 Key: ZOOKEEPER-913
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.1
Reporter: Anthony Urso
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.3.3, 3.4.0

 Attachments: zk-build.patch, zk-version.patch, ZOOKEEPER-913.patch


 Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
 parse 3.3.2-dev.
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 2-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  [java]   at java.lang.Integer.parseInt(Integer.java:481)
  [java]   at java.lang.Integer.parseInt(Integer.java:514)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 1

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



[jira] Commented: (ZOOKEEPER-913) Version parser fails to parse 3.3.2-dev from build.xml.

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-913:
-

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

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

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

This message is automatically generated.

 Version parser fails to parse 3.3.2-dev from build.xml.
 -

 Key: ZOOKEEPER-913
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-913
 Project: Zookeeper
  Issue Type: Bug
  Components: build
Affects Versions: 3.3.1
Reporter: Anthony Urso
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.3.3, 3.4.0

 Attachments: zk-build.patch, zk-version.patch, ZOOKEEPER-913.patch


 Cannot build 3.3.1 from release tarball do to VerGen parser inability to 
 parse 3.3.2-dev.
 version-info:
  [java] All version-related parameters must be valid integers!
  [java] Exception in thread main java.lang.NumberFormatException: For 
 input string: 2-dev
  [java]   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  [java]   at java.lang.Integer.parseInt(Integer.java:481)
  [java]   at java.lang.Integer.parseInt(Integer.java:514)
  [java]   at 
 org.apache.zookeeper.version.util.VerGen.main(VerGen.java:131)
  [java] Java Result: 1

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



[jira] Commented: (ZOOKEEPER-920) L7 (application layer) ping support

2010-11-09 Thread Chang Song (JIRA)

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

Chang Song commented on ZOOKEEPER-920:
--

Michi. Let me rephrase my question ;)
I was wondering if there is any standard way in unit testing Zookeeper C client 
library.
If not, can I simply write something in Python?

thank you.



 L7 (application layer) ping support
 ---

 Key: ZOOKEEPER-920
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-920
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client
Affects Versions: 3.3.1
Reporter: Chang Song
Assignee: Chang Song
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-920.patch


 Zookeeper is used in applications where fault tolerance is important. Its 
 client i/o thread send/recv heartbeats to/fro Zookeeper ensemble to stay 
 connected. However healthy heartbeat does not always means that the 
 application that uses Zookeeper client is in good health, it only means that 
 ZK client thread is in good health.
 This I needed something that can tagged onto Zookeeper ping that represents 
 L7 (application) health as well.
 I have modified C client source to support this in minimal way. I am new to 
 Zookeeper, so please code review this code.  I am actually using this code in 
 our in-house solution.
 https://github.com/tru64ufs/zookeeper/commit/2196d6d5114a2fd2c0a3bc9a55f4494d47d2aece
 Thank you very much.

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



[jira] Commented: (ZOOKEEPER-920) L7 (application layer) ping support

2010-11-09 Thread Michi Mutsuzaki (JIRA)

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

Michi Mutsuzaki commented on ZOOKEEPER-920:
---

I think it's better if you add a test to src/c/tests/TestClient.cc. 

Thanks!
--Michi

 L7 (application layer) ping support
 ---

 Key: ZOOKEEPER-920
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-920
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client
Affects Versions: 3.3.1
Reporter: Chang Song
Assignee: Chang Song
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-920.patch


 Zookeeper is used in applications where fault tolerance is important. Its 
 client i/o thread send/recv heartbeats to/fro Zookeeper ensemble to stay 
 connected. However healthy heartbeat does not always means that the 
 application that uses Zookeeper client is in good health, it only means that 
 ZK client thread is in good health.
 This I needed something that can tagged onto Zookeeper ping that represents 
 L7 (application) health as well.
 I have modified C client source to support this in minimal way. I am new to 
 Zookeeper, so please code review this code.  I am actually using this code in 
 our in-house solution.
 https://github.com/tru64ufs/zookeeper/commit/2196d6d5114a2fd2c0a3bc9a55f4494d47d2aece
 Thank you very much.

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



[jira] Commented: (ZOOKEEPER-920) L7 (application layer) ping support

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-920:


In general unit tests for the c binding is an area we could use more help with 
(more tests). If you're interested. :-)

 L7 (application layer) ping support
 ---

 Key: ZOOKEEPER-920
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-920
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client
Affects Versions: 3.3.1
Reporter: Chang Song
Assignee: Chang Song
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-920.patch


 Zookeeper is used in applications where fault tolerance is important. Its 
 client i/o thread send/recv heartbeats to/fro Zookeeper ensemble to stay 
 connected. However healthy heartbeat does not always means that the 
 application that uses Zookeeper client is in good health, it only means that 
 ZK client thread is in good health.
 This I needed something that can tagged onto Zookeeper ping that represents 
 L7 (application) health as well.
 I have modified C client source to support this in minimal way. I am new to 
 Zookeeper, so please code review this code.  I am actually using this code in 
 our in-house solution.
 https://github.com/tru64ufs/zookeeper/commit/2196d6d5114a2fd2c0a3bc9a55f4494d47d2aece
 Thank you very much.

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



[jira] Commented: (ZOOKEEPER-922) enable faster timeout of sessions in case of unexpected socket disconnect

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-922:


@camille NP, although it makes it easier for us (reviewers) if all the patches 
are consistent. For future reference then. Thanks.

ps. you might get more insightful review if you post to apache's new 
reviewboard server: https://reviews.apache.org

Regards.

 enable faster timeout of sessions in case of unexpected socket disconnect
 -

 Key: ZOOKEEPER-922
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-922
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Camille Fournier
Assignee: Camille Fournier
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-922.patch


 In the case when a client connection is closed due to socket error instead of 
 the client calling close explicitly, it would be nice to enable the session 
 associated with that client to time out faster than the negotiated session 
 timeout. This would enable a zookeeper ensemble that is acting as a dynamic 
 discovery provider to remove ephemeral nodes for crashed clients quickly, 
 while allowing for a longer heartbeat-based timeout for java clients that 
 need to do long stop-the-world GC. 
 I propose doing this by setting the timeout associated with the crashed 
 session to minSessionTimeout.

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



[jira] Updated: (ZOOKEEPER-906) Improve C client connection reliability by making it sleep between reconnect attempts as in Java Client

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-906:
---

Status: Open  (was: Patch Available)

Cancelling patch, needs test(s).

 Improve C client connection reliability by making it sleep between reconnect 
 attempts as in Java Client
 ---

 Key: ZOOKEEPER-906
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-906
 Project: Zookeeper
  Issue Type: Improvement
  Components: c client
Affects Versions: 3.3.1
Reporter: Radu Marin
Assignee: Radu Marin
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-906.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently, when a C client get disconnected, it retries a couple of hosts 
 (not all) with no delay between attempts and then if it doesn't succeed it 
 sleeps for 1/3 session expiration timeout period before trying again.
 In the worst case the disconnect event can occur after 2/3 of session 
 expiration timeout has past, and sleeping for even more 1/3 session timeout 
 will cause a session loss in most of the times.
 A better approach is to check all hosts but with random delay between 
 reconnect attempts. Also the delay must be independent of session timeout so 
 if we increase the session timeout we also increase the number of available 
 attempts.
 This improvement covers the case when the C client experiences network 
 problems for a short period of time and is not able to reach any zookeeper 
 hosts.
 Java client already uses this logic and works very good.

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



[jira] Updated: (ZOOKEEPER-877) zkpython does not work with python3.1

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-877:
---

Status: Open  (was: Patch Available)

Hi TuxRacer, is it possible for you to re-submit this as a single patch file? 
We generally request all changes in that format, to ensure that it's committed 
the way you intended (also helps with a bunch of other things like reviewing 
and hudsonqabot, etc...) here are the basic details: 
http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
(basically: svn checkout the code, make changes, svn diff and submit the 
result as ZOOKEEPER-877.patch, you may need to svn add if you are adding new 
files).

 zkpython does not work with python3.1
 -

 Key: ZOOKEEPER-877
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-877
 Project: Zookeeper
  Issue Type: Bug
  Components: contrib-bindings
Affects Versions: 3.3.1
 Environment: linux+python3.1
Reporter: TuxRacer
Assignee: TuxRacer
 Fix For: 3.4.0

 Attachments: Doc.tgz, tests_py3k.tgz, zookeeper.c, 
 zookeeper.c.patch.v1, zookeeper.c.patch.v2, zookeeper.c.v2, zookeeper.rst


 as written in the contrib/zkpython/README file:
 Python = 2.6 is required. We have tested against 2.6. We have not tested 
 against 3.x.
 this is probably more a 'new feature' request than a bug; anyway compiling 
 the pythn module and calling it returns an error at load time:
 python3.1
 Python 3.1.2 (r312:79147, May  8 2010, 16:36:46) 
 [GCC 4.4.4] on linux2
 Type help, copyright, credits or license for more information.
  import zookeeper
 Traceback (most recent call last):
   File stdin, line 1, in module
 ImportError: /usr/local/lib/python3.1/dist-packages/zookeeper.so: undefined 
 symbol: PyString_AsString
 are there any plan to support Python3.X?
 I also tried to write a 3.1 ctypes wrapper but the C API seems in fact to be 
 written in C++, so python ctypes cannot be used.

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



[jira] Updated: (ZOOKEEPER-874) FileTxnSnapLog.restore does not call listener

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-874:
---

Status: Open  (was: Patch Available)

Cancelling patch, could you provide a tests that verifies this issue is 
addressed? Thanks.

 FileTxnSnapLog.restore does not call listener
 -

 Key: ZOOKEEPER-874
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-874
 Project: Zookeeper
  Issue Type: Bug
  Components: leaderElection
Affects Versions: 3.3.1
Reporter: Diogo
Assignee: Diogo
Priority: Trivial
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-874.patch


 FileTxnSnapLog.restore() does not call listener passed as parameter. The 
 result is that the commitLogs list is empty. When a follower connects to the 
 leader, the leader is forced to send a snapshot to the follower instead of a 
 couple of requests and commits.

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



[jira] Updated: (ZOOKEEPER-823) update ZooKeeper java client to optionally use Netty for connections

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-823:
---

Status: Open  (was: Patch Available)

cancelling for now given Thomas is working on this via a new avenue.

 update ZooKeeper java client to optionally use Netty for connections
 

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

 Attachments: NettyNettySuiteTest.rtf, 
 TEST-org.apache.zookeeper.test.NettyNettySuiteTest.txt.gz, 
 testDisconnectedAddAuth_FAILURE, testWatchAutoResetWithPending_FAILURE, 
 ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, 
 ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, 
 ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, ZOOKEEPER-823.patch, 
 ZOOKEEPER-823.patch, ZOOKEEPER-823.patch


 This jira will port the client side connection code to use netty rather than 
 direct nio.

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



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

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-784:
---

Status: Open  (was: Patch Available)

Looks like the patch is failing to apply in one hunk, please resubmit. thanks.

 [exec] 1 out of 2 hunks FAILED -- saving rejects to file 
src/java/main/org/apache/zookeeper/Watcher.java.rej


 server-side functionality for read-only mode
 

 Key: ZOOKEEPER-784
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-784
 Project: Zookeeper
  Issue Type: Sub-task
  Components: server
Reporter: Sergey Doroshenko
Assignee: Sergey Doroshenko
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
 ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
 ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 
 ZOOKEEPER-784.patch, ZOOKEEPER-784.patch


 As per http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode , create 
 ReadOnlyZooKeeperServer which comes into play when peer is partitioned.

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



[jira] Updated: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-780:
---

Status: Open  (was: Patch Available)

Andrei, this is a good fix, could you create a test for this? Thanks.

 zkCli.sh  generates a ArrayIndexOutOfBoundsException 
 -

 Key: ZOOKEEPER-780
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
 Project: Zookeeper
  Issue Type: Bug
  Components: scripts
Affects Versions: 3.3.1
 Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
Reporter: Miguel Correia
Assignee: Andrei Savu
Priority: Minor
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch, 
 ZOOKEEPER-780.patch


 I'm starting to play with Zookeeper so I'm still running it in standalone 
 mode. This is not a big issue, but here it goes for the records. 
 I've run zkCli.sh to run some commands in the server. I created a znode 
 /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
 include the data: an exception was generated and zkCli-sh crashed, instead of 
 just showing an error. I tried a few variations and it seems like the problem 
 is not including the data.
 A copy of the screen:
 [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
 Created /groups
 [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 3
   at 
 org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
   at 
 org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

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



[jira] Updated: (ZOOKEEPER-740) zkpython leading to segfault on zookeeper

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-740:
---

Status: Open  (was: Patch Available)

Looks like the patch is failing to apply. Could someone update and resubmit?

 zkpython leading to segfault on zookeeper
 -

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

 Attachments: ZOOKEEPER-740.patch


 The program that we are implementing uses the python binding for zookeeper 
 but sometimes it crash with segfault; here is the bt from gdb:
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0xad244b70 (LWP 28216)]
 0x080611d5 in PyObject_Call (func=0x862fab0, arg=0x8837194, kw=0x0)
 at ../Objects/abstract.c:2488
 2488../Objects/abstract.c: No such file or directory.
 in ../Objects/abstract.c
 (gdb) bt
 #0  0x080611d5 in PyObject_Call (func=0x862fab0, arg=0x8837194, kw=0x0)
 at ../Objects/abstract.c:2488
 #1  0x080d6ef2 in PyEval_CallObjectWithKeywords (func=0x862fab0,
 arg=0x8837194, kw=0x0) at ../Python/ceval.c:3575
 #2  0x080612a0 in PyObject_CallObject (o=0x862fab0, a=0x8837194)
 at ../Objects/abstract.c:2480
 #3  0x0047af42 in watcher_dispatch (zzh=0x86174e0, type=-1, state=1,
 path=0x86337c8 , context=0x8588660) at src/c/zookeeper.c:314
 #4  0x00496559 in do_foreach_watcher (zh=0x86174e0, type=-1, state=1,
 path=0x86337c8 , list=0xa5354140) at src/zk_hashtable.c:275
 #5  deliverWatchers (zh=0x86174e0, type=-1, state=1, path=0x86337c8 ,
 list=0xa5354140) at src/zk_hashtable.c:317
 #6  0x0048ae3c in process_completions (zh=0x86174e0) at src/zookeeper.c:1766
 #7  0x0049706b in do_completion (v=0x86174e0) at src/mt_adaptor.c:333
 #8  0x0013380e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
 #9  0x002578de in clone () from /lib/tls/i686/cmov/libc.so.6

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



[jira] Updated: (ZOOKEEPER-756) some cleanup and improvements for zooinspector

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-756:
---

Status: Open  (was: Patch Available)

The patch is failing to apply, please update against the latest source base and 
resubmit, thanks!

 some cleanup and improvements for zooinspector
 --

 Key: ZOOKEEPER-756
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-756
 Project: Zookeeper
  Issue Type: Improvement
  Components: contrib
Affects Versions: 3.3.0
Reporter: Thomas Koch
Assignee: Colin Goodheart-Smithe
 Fix For: 3.4.0

 Attachments: zooInspectorChanges.patch


 Copied from the already closed ZOOKEEPER-678:
 * specify the exact URL, where the icons are from. It's best to include the 
 link also in the NOTICE.txt file.
 It seems, that zooinspector finds it's icons only if the icons folder is in 
 the current path. But when I install zooinspector as part of the Zookeeper 
 Debian package, I want to be able to call it regardless of the current path.
 Could you use getRessources or something so that I can point to the icons 
 location from the wrapper shell script?
 Can I place the zooinspector config files in /etc/zookeeper/zooinspector/ ? 
 Could I give zooinspector a property to point to the config file location?
 There are several places, where viewers is missspelled as Veiwers. Please 
 do a case insensitive search for veiw to correct these. Even the config 
 file defaultNodeVeiwers.cfg is missspelled like this. This has the 
 potential to confuse the hell out of people when debugging something!

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



[jira] Commented: (ZOOKEEPER-906) Improve C client connection reliability by making it sleep between reconnect attempts as in Java Client

2010-11-09 Thread Radu Marin (JIRA)

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

Radu Marin commented on ZOOKEEPER-906:
--

 -1 core tests. The patch failed core unit tests.
I find a little hard to interpret the unit test results. Can someone explain 
what exactly failed with the new patch ?
Thanks.

 Improve C client connection reliability by making it sleep between reconnect 
 attempts as in Java Client
 ---

 Key: ZOOKEEPER-906
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-906
 Project: Zookeeper
  Issue Type: Improvement
  Components: c client
Affects Versions: 3.3.1
Reporter: Radu Marin
Assignee: Radu Marin
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-906.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently, when a C client get disconnected, it retries a couple of hosts 
 (not all) with no delay between attempts and then if it doesn't succeed it 
 sleeps for 1/3 session expiration timeout period before trying again.
 In the worst case the disconnect event can occur after 2/3 of session 
 expiration timeout has past, and sleeping for even more 1/3 session timeout 
 will cause a session loss in most of the times.
 A better approach is to check all hosts but with random delay between 
 reconnect attempts. Also the delay must be independent of session timeout so 
 if we increase the session timeout we also increase the number of available 
 attempts.
 This improvement covers the case when the C client experiences network 
 problems for a short period of time and is not able to reach any zookeeper 
 hosts.
 Java client already uses this logic and works very good.

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



[jira] Commented: (ZOOKEEPER-906) Improve C client connection reliability by making it sleep between reconnect attempts as in Java Client

2010-11-09 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-906:


Hi Radu, yes I agree, difficult to parse in some cases. Nigel/Giri/buildteam 
are working to improve, WIP.

bq. -1 tests included. The patch doesn't appear to include any new or modified 
tests.

this is the main issue - the patch doesn't include any tests validating the 
modified functionality.

bq. -1 on the core tests

You can't see it in the summary but if you look at the hudson raw console, 
near the end, the c tests have failed. (d/l the console and open in editor)

This might be a false failure though, I saw similar on another test. I've 
notified Nigel about it and he's going to take a look.


 Improve C client connection reliability by making it sleep between reconnect 
 attempts as in Java Client
 ---

 Key: ZOOKEEPER-906
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-906
 Project: Zookeeper
  Issue Type: Improvement
  Components: c client
Affects Versions: 3.3.1
Reporter: Radu Marin
Assignee: Radu Marin
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-906.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 Currently, when a C client get disconnected, it retries a couple of hosts 
 (not all) with no delay between attempts and then if it doesn't succeed it 
 sleeps for 1/3 session expiration timeout period before trying again.
 In the worst case the disconnect event can occur after 2/3 of session 
 expiration timeout has past, and sleeping for even more 1/3 session timeout 
 will cause a session loss in most of the times.
 A better approach is to check all hosts but with random delay between 
 reconnect attempts. Also the delay must be independent of session timeout so 
 if we increase the session timeout we also increase the number of available 
 attempts.
 This improvement covers the case when the C client experiences network 
 problems for a short period of time and is not able to reach any zookeeper 
 hosts.
 Java client already uses this logic and works very good.

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



[jira] Commented: (ZOOKEEPER-850) Switch from log4j to slf4j

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-850:
-

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

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

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

This message is automatically generated.

 Switch from log4j to slf4j
 --

 Key: ZOOKEEPER-850
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850
 Project: Zookeeper
  Issue Type: Improvement
  Components: java client
Affects Versions: 3.3.1
Reporter: Olaf Krische
Assignee: Olaf Krische
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-3.3.1-log4j-slf4j-20101031.patch.bz2, 
 ZOOKEEPER-3.4.0-log4j-slf4j-20101102.patch.bz2, ZOOKEEPER-850.patch


 Hello,
 i would like to see slf4j integrated into the zookeeper instead of relying 
 explicitly on log4j.
 slf4j is an abstract logging framework. There are adapters from slf4j to many 
 logger implementations, one of them is log4j.
 The decision which log engine to use i dont like to make so early.
 This would help me to embed zookeeper in my own applications (which use a 
 different logger implemenation, but slf4j is the basis)
 What do you think?
 (as i can see, those slf4j request flood all other projects on apache as well 
 :-)
 Maybe for 3.4 or 4.0?
 I can offer a patchset, i have experience in such an migration already. :-)

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



[jira] Commented: (ZOOKEEPER-909) Extract NIO specific code from ClientCnxn

2010-11-09 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-909:
-

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

+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 appears to have generated 1 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: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/22//testReport/
Findbugs warnings: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/22//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/22//console

This message is automatically generated.

 Extract NIO specific code from ClientCnxn
 -

 Key: ZOOKEEPER-909
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-909
 Project: Zookeeper
  Issue Type: Sub-task
  Components: java client
Reporter: Thomas Koch
Assignee: Thomas Koch
 Fix For: 3.4.0

 Attachments: ClientCnxnSocketNetty.java, ZOOKEEPER-909.patch, 
 ZOOKEEPER-909.patch, ZOOKEEPER-909.patch, ZOOKEEPER-909.patch, 
 ZOOKEEPER-909.patch


 This patch is mostly the same patch as my last one for ZOOKEEPER-823 minus 
 everything Netty related. This means this patch only extract all NIO specific 
 code in the class ClientCnxnSocketNIO which extends ClientCnxnSocket.
 I've redone this patch from current trunk step by step now and couldn't find 
 any logical error. I've already done a couple of successful test runs and 
 will continue to do so this night.
 It would be nice, if we could apply this patch as soon as possible to trunk. 
 This allows us to continue to work on the netty integration without blocking 
 the ClientCnxn class. Adding Netty after this patch should be only a matter 
 of adding the ClientCnxnSocketNetty class with the appropriate test cases.
 You could help me by reviewing the patch and by running it on whatever test 
 server you have available. Please send me any complete failure log you should 
 encounter to thomas at koch point ro. Thx!
 Update: Until now, I've collected 8 successful builds in a row!

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Benjamin Reed (JIRA)

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

Benjamin Reed commented on ZOOKEEPER-925:
-

this is pretty cool! we can generate pdfs by using doxia converter to go from 
confluence to latex.

 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt
Assignee: Patrick Hunt
 Attachments: ZOOKEEPER-925.patch


 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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



[jira] Resolved: (ZOOKEEPER-926) Fork Hadoop common's test-patch.sh and modify for Zookeeper

2010-11-09 Thread Nigel Daley (JIRA)

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

Nigel Daley resolved ZOOKEEPER-926.
---

Resolution: Fixed

Committed. Resolving this issue for now.  Open new issues for further 
fixes/enhancements.

 Fork Hadoop common's test-patch.sh and modify for Zookeeper
 ---

 Key: ZOOKEEPER-926
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-926
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Nigel Daley
Assignee: Nigel Daley
 Fix For: 3.4.0

 Attachments: ZOOKEEPER-926.patch


 Zookeeper currently uses the test-patch.sh script from the Hadoop nightly 
 dir.  This is now out of date.  I propose we just copy the updated one in 
 Hadoop common and then modify for ZK.  This will also help as ZK moves out of 
 Hadoop to it's own TLP.  

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



[jira] Commented: (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation

2010-11-09 Thread Benjamin Reed (JIRA)

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

Benjamin Reed commented on ZOOKEEPER-925:
-

since maven generates the doc without requiring preinstalled tools. i don't 
think it is onerous at all to just check in the sources and require users to 
compile the doc if they are using trunk.

 Consider maven site generation to replace our forrest site and documentation 
 generation
 ---

 Key: ZOOKEEPER-925
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925
 Project: Zookeeper
  Issue Type: Wish
  Components: documentation
Reporter: Patrick Hunt
Assignee: Patrick Hunt
 Attachments: ZOOKEEPER-925.patch


 See WHIRR-19 for some background.
 In whirr we looked at a number of site/doc generation facilities. In the end 
 Maven site generation plugin turned out to be by far the best option. You can 
 see our nascent site here (no attempt at styling,etc so far):
 http://incubator.apache.org/whirr/
 In particular take a look at the quick start:
 http://incubator.apache.org/whirr/quick-start-guide.html
 which was generated from
 http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence
 notice this was standard wiki markup (confluence wiki markup, same as 
 available from apache)
 You can read more about mvn site plugin here:
 http://maven.apache.org/guides/mini/guide-site.html
 Notice that other formats are available, not just confluence markup, also 
 note that you can use different markup formats if you like in the same site 
 (although probably not a great idea, but in some cases might be handy, for 
 example whirr uses the confluence wiki, so we can pretty much copy/paste 
 source docs from wiki to our site (svn) if we like)
 Re maven vs our current ant based build. It's probably a good idea for us to 
 move the build to maven at some point. We could initially move just the doc 
 generation, and then incrementally move functionality from build.xml to mvn 
 over a longer time period.

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