[jira] Created: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server

2008-10-22 Thread Benjamin Reed (JIRA)
SetWatches needs to be the first message after auth messages to the server
--

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


When the ZooKeeper java client  makes a connection it queues a SetWatches  
request. The problem is that it puts the request at the end of the outgoing 
requests. This means that watches for requests that were queued before the 
connection is made and after the disconnect may improperly get their watches 
triggered.

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



[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server

2008-10-22 Thread Benjamin Reed (JIRA)

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

Benjamin Reed updated ZOOKEEPER-204:


Attachment: ZOOKEEPER-204.patch

This patch has a test case for the condition. It also fixes the problem by 
queuing the SetWatches right after the auth packets and before any other 
packets. While fixing the problem I also fixed the problem of exceptions that 
happen in callbacks killing the dispatch thread.

 SetWatches needs to be the first message after auth messages to the server
 --

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

 Attachments: ZOOKEEPER-204.patch


 When the ZooKeeper java client  makes a connection it queues a SetWatches  
 request. The problem is that it puts the request at the end of the outgoing 
 requests. This means that watches for requests that were queued before the 
 connection is made and after the disconnect may improperly get their watches 
 triggered.

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



[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server

2008-10-22 Thread Benjamin Reed (JIRA)

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

Benjamin Reed updated ZOOKEEPER-204:


Affects Version/s: (was: 3.0.0)
   3.1.0
   Status: Patch Available  (was: Open)

 SetWatches needs to be the first message after auth messages to the server
 --

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

 Attachments: ZOOKEEPER-204.patch


 When the ZooKeeper java client  makes a connection it queues a SetWatches  
 request. The problem is that it puts the request at the end of the outgoing 
 requests. This means that watches for requests that were queued before the 
 connection is made and after the disconnect may improperly get their watches 
 triggered.

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



[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server

2008-10-22 Thread Benjamin Reed (JIRA)

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

Benjamin Reed updated ZOOKEEPER-204:


Assignee: (was: Benjamin Reed)

 SetWatches needs to be the first message after auth messages to the server
 --

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

 Attachments: ZOOKEEPER-204.patch


 When the ZooKeeper java client  makes a connection it queues a SetWatches  
 request. The problem is that it puts the request at the end of the outgoing 
 requests. This means that watches for requests that were queued before the 
 connection is made and after the disconnect may improperly get their watches 
 triggered.

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



[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server

2008-10-22 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-204:
---

Fix Version/s: (was: 3.0.0)
   3.1.0
 Assignee: Benjamin Reed
Affects Version/s: (was: 3.1.0)
   3.0.0

 SetWatches needs to be the first message after auth messages to the server
 --

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

 Attachments: ZOOKEEPER-204.patch


 When the ZooKeeper java client  makes a connection it queues a SetWatches  
 request. The problem is that it puts the request at the end of the outgoing 
 requests. This means that watches for requests that were queued before the 
 connection is made and after the disconnect may improperly get their watches 
 triggered.

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



[jira] Assigned: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server

2008-10-22 Thread Patrick Hunt (JIRA)

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

Patrick Hunt reassigned ZOOKEEPER-204:
--

Assignee: Benjamin Reed

 SetWatches needs to be the first message after auth messages to the server
 --

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

 Attachments: ZOOKEEPER-204.patch


 When the ZooKeeper java client  makes a connection it queues a SetWatches  
 request. The problem is that it puts the request at the end of the outgoing 
 requests. This means that watches for requests that were queued before the 
 connection is made and after the disconnect may improperly get their watches 
 triggered.

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



[VOTE] Release ZooKeeper 3.0.0 (candidate 0)

2008-10-22 Thread Patrick Hunt
I've created a candidate build for the first Apache release of ZooKeeper 
- version 3.0.0.


*** Please download, test and VOTE before the
*** vote closes EOD on Friday, October 24.***

http://people.apache.org/~phunt/zookeeper-3.0.0-candidate-0/

Patrick



[jira] Commented: (ZOOKEEPER-203) fix datadir typo in releasenotes

2008-10-22 Thread Hudson (JIRA)

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

Hudson commented on ZOOKEEPER-203:
--

Integrated in ZooKeeper-trunk #121 (See 
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/121/])
. fix datadir typo in releasenotes


 fix datadir typo in releasenotes
 

 Key: ZOOKEEPER-203
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-203
 Project: Zookeeper
  Issue Type: Bug
  Components: documentation
Affects Versions: 3.0.0
Reporter: Patrick Hunt
Assignee: Patrick Hunt
Priority: Minor
 Fix For: 3.0.0

 Attachments: ZOOKEEPER-203.patch


 typo in releasenotes note on datalog/data dirs.

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



[jira] Commented: (ZOOKEEPER-145) write detailed release notes for users migrating from 2.x to 3.0

2008-10-22 Thread Hudson (JIRA)

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

Hudson commented on ZOOKEEPER-145:
--

Integrated in ZooKeeper-trunk #121 (See 
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/121/])
. write detailed release notes for users migrating from 2.x to 3.0


 write detailed release notes for users migrating from 2.x to 3.0
 

 Key: ZOOKEEPER-145
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-145
 Project: Zookeeper
  Issue Type: Task
  Components: c client, documentation, java client
Affects Versions: 3.0.0
Reporter: Patrick Hunt
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.0.0

 Attachments: ZOOKEEPER-145.patch


 We need to write detailed release notes that detail how c and java client API 
 users as well as zk server administrators migrate from 2.x to 3.x zookeeper 
 release.

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



[jira] Commented: (ZOOKEEPER-43) Server side of the auto reset watches patch

2008-10-22 Thread Hudson (JIRA)

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

Hudson commented on ZOOKEEPER-43:
-

Integrated in ZooKeeper-trunk #121 (See 
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/121/])
. Server side of auto reset watches.


 Server side of the auto reset watches patch
 ---

 Key: ZOOKEEPER-43
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-43
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Patrick Hunt
Assignee: Benjamin Reed
 Fix For: 3.0.0

 Attachments: ZOOKEEPER-43.patch, ZOOKEEPER-43.patch, 
 ZOOKEEPER-43.patch, ZOOKEEPER-43.patch, ZOOKEEPER-43.patch, ZOOKEEPER-43.patch


 Moved from SourceForge to Apache.
 http://sourceforge.net/tracker/index.php?func=detailaid=1975262group_id=209147atid=1008546

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



[jira] Commented: (ZOOKEEPER-200) the magic number for snapshot and log must be different (currently same)

2008-10-22 Thread Hudson (JIRA)

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

Hudson commented on ZOOKEEPER-200:
--

Integrated in ZooKeeper-trunk #121 (See 
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/121/])
. the magic number for snapshot and log must be different


 the magic number for snapshot and log must be different (currently same)
 

 Key: ZOOKEEPER-200
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-200
 Project: Zookeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.0.0
Reporter: Patrick Hunt
Assignee: Patrick Hunt
 Fix For: 3.0.0

 Attachments: ZOOKEEPER-200.patch, ZOOKEEPER-200.patch


 the magic number for the snapshot and transaction logs are currently the same 
 - they should be different. Also the magic numbers should also be more 
 indicative of the type of file (currently AK47 for both, not very useful in 
 determining type of file)

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



[jira] Commented: (ZOOKEEPER-23) Auto reset of watches on reconnect

2008-10-22 Thread Hudson (JIRA)

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

Hudson commented on ZOOKEEPER-23:
-

Integrated in ZooKeeper-trunk #121 (See 
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/121/])
. Auto reset of watches on reconnect


 Auto reset of watches on reconnect
 --

 Key: ZOOKEEPER-23
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-23
 Project: Zookeeper
  Issue Type: New Feature
  Components: c client, java client
Reporter: Patrick Hunt
Assignee: Benjamin Reed
 Fix For: 3.0.0

 Attachments: ZOOKEEPER-23.patch


 Moved from SourceForge to Apache.
 http://sourceforge.net/tracker/index.php?func=detailaid=1831413group_id=209147atid=1008547

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



[jira] Commented: (ZOOKEEPER-201) validate magic number when reading snapshot and transaction logs

2008-10-22 Thread Hudson (JIRA)

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

Hudson commented on ZOOKEEPER-201:
--

Integrated in ZooKeeper-trunk #121 (See 
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/121/])
. validate magic number when reading snapshot and transaction


 validate magic number when reading snapshot and transaction logs
 

 Key: ZOOKEEPER-201
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-201
 Project: Zookeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.0.0
Reporter: Patrick Hunt
Assignee: Mahadev konar
Priority: Blocker
 Fix For: 3.0.0

 Attachments: ZOOKEEPER-201.patch


 The snapshot and transaction log files are not validating the magic numbers 
 when read.
 Mahadev, can you update the code and tests for this? Possible for 3.0 or wait 
 post 3.0? (feel free to fix now or reassign version)
 Please add tests for this.

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



[jira] Commented: (ZOOKEEPER-202) Phantom ephemeral node

2008-10-22 Thread Flavio Paiva Junqueira (JIRA)

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

Flavio Paiva Junqueira commented on ZOOKEEPER-202:
--

Servers are running 1.2.0-130, built on 04/14/2008.

 Phantom ephemeral node
 --

 Key: ZOOKEEPER-202
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-202
 Project: Zookeeper
  Issue Type: Bug
Reporter: Flavio Paiva Junqueira

 One of our users has observed that an ephemeral znode had gone away once its 
 creator had disconnected according to the leader, but one follower believed 
 that it existed long after the znode had been deleted. Apparently the 
 follower was never going to delete it. Because the leader wouldn't recognize 
 the znode as an existing one, any attempt to delete the znode failed.  We 
 have to investigate if this is related to any known bug, although, to my 
 knowledge, this is the first time it happens. It is important to note that 
 the user was running an older version of our code.

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



[jira] Commented: (ZOOKEEPER-202) Phantom ephemeral node

2008-10-22 Thread Flavio Paiva Junqueira (JIRA)

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

Flavio Paiva Junqueira commented on ZOOKEEPER-202:
--

Mahadev, Is this the one you're talking about:  1982992   concurrency issue in 
the zookeeper leader code?



 Phantom ephemeral node
 --

 Key: ZOOKEEPER-202
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-202
 Project: Zookeeper
  Issue Type: Bug
Reporter: Flavio Paiva Junqueira

 One of our users has observed that an ephemeral znode had gone away once its 
 creator had disconnected according to the leader, but one follower believed 
 that it existed long after the znode had been deleted. Apparently the 
 follower was never going to delete it. Because the leader wouldn't recognize 
 the znode as an existing one, any attempt to delete the znode failed.  We 
 have to investigate if this is related to any known bug, although, to my 
 knowledge, this is the first time it happens. It is important to note that 
 the user was running an older version of our code.

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



[jira] Commented: (ZOOKEEPER-202) Phantom ephemeral node

2008-10-22 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-202:


1.2.0-130??? That's not a zk version number, any idea which version of zk this 
corresponds to? (sourceforge has 2.x.x version numbers for example)

 Phantom ephemeral node
 --

 Key: ZOOKEEPER-202
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-202
 Project: Zookeeper
  Issue Type: Bug
Reporter: Flavio Paiva Junqueira

 One of our users has observed that an ephemeral znode had gone away once its 
 creator had disconnected according to the leader, but one follower believed 
 that it existed long after the znode had been deleted. Apparently the 
 follower was never going to delete it. Because the leader wouldn't recognize 
 the znode as an existing one, any attempt to delete the znode failed.  We 
 have to investigate if this is related to any known bug, although, to my 
 knowledge, this is the first time it happens. It is important to note that 
 the user was running an older version of our code.

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



[jira] Commented: (ZOOKEEPER-202) Phantom ephemeral node

2008-10-22 Thread Benjamin Reed (JIRA)

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

Benjamin Reed commented on ZOOKEEPER-202:
-

I think it's 2.1.0 from sourceforge. That release was done on 4/29/2008. (It 
might have been built earlier.)

The latest sourceforge release 2.2.1 has the fix.

 Phantom ephemeral node
 --

 Key: ZOOKEEPER-202
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-202
 Project: Zookeeper
  Issue Type: Bug
Reporter: Flavio Paiva Junqueira

 One of our users has observed that an ephemeral znode had gone away once its 
 creator had disconnected according to the leader, but one follower believed 
 that it existed long after the znode had been deleted. Apparently the 
 follower was never going to delete it. Because the leader wouldn't recognize 
 the znode as an existing one, any attempt to delete the znode failed.  We 
 have to investigate if this is related to any known bug, although, to my 
 knowledge, this is the first time it happens. It is important to note that 
 the user was running an older version of our code.

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



[jira] Commented: (ZOOKEEPER-149) c interface is missing tests against java server (mock only)

2008-10-22 Thread Benjamin Reed (JIRA)

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

Benjamin Reed commented on ZOOKEEPER-149:
-

The system test only tests the watcher code. We should leave this issue open 
until we get a more complete suite of system tests.

 c interface is missing tests against java server (mock only)
 

 Key: ZOOKEEPER-149
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-149
 Project: Zookeeper
  Issue Type: Improvement
  Components: c client
Reporter: Patrick Hunt
Assignee: Patrick Hunt
 Fix For: 3.1.0


 The c client interface has unit tests but they are against mock server 
 implementations only. We need to add tests for the c interface against live 
 java server.

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



[jira] Resolved: (ZOOKEEPER-202) Phantom ephemeral node

2008-10-22 Thread Flavio Paiva Junqueira (JIRA)

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

Flavio Paiva Junqueira resolved ZOOKEEPER-202.
--

Resolution: Fixed
  Assignee: Flavio Paiva Junqueira

This issue has already been fixed in a previous version.

 Phantom ephemeral node
 --

 Key: ZOOKEEPER-202
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-202
 Project: Zookeeper
  Issue Type: Bug
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira

 One of our users has observed that an ephemeral znode had gone away once its 
 creator had disconnected according to the leader, but one follower believed 
 that it existed long after the znode had been deleted. Apparently the 
 follower was never going to delete it. Because the leader wouldn't recognize 
 the znode as an existing one, any attempt to delete the znode failed.  We 
 have to investigate if this is related to any known bug, although, to my 
 knowledge, this is the first time it happens. It is important to note that 
 the user was running an older version of our code.

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



[jira] Commented: (ZOOKEEPER-202) Phantom ephemeral node

2008-10-22 Thread Mahadev konar (JIRA)

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

Mahadev konar commented on ZOOKEEPER-202:
-

@flavio 
yes thats the bug
just adding a link here in case someone needs a reference to it...


http://sourceforge.net/tracker/index.php?func=detailaid=1982992group_id=209147atid=1008546



 Phantom ephemeral node
 --

 Key: ZOOKEEPER-202
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-202
 Project: Zookeeper
  Issue Type: Bug
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira

 One of our users has observed that an ephemeral znode had gone away once its 
 creator had disconnected according to the leader, but one follower believed 
 that it existed long after the znode had been deleted. Apparently the 
 follower was never going to delete it. Because the leader wouldn't recognize 
 the znode as an existing one, any attempt to delete the znode failed.  We 
 have to investigate if this is related to any known bug, although, to my 
 knowledge, this is the first time it happens. It is important to note that 
 the user was running an older version of our code.

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



Re: [VOTE] Release ZooKeeper 3.0.0 (candidate 0)

2008-10-22 Thread Mahadev Konar
+1 


mahadev


On 10/22/08 8:59 AM, Benjamin Reed [EMAIL PROTECTED] wrote:

 +1
 
 -Original Message-
 From: Patrick Hunt [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, October 21, 2008 11:29 PM
 To: zookeeper-dev@hadoop.apache.org
 Subject: [VOTE] Release ZooKeeper 3.0.0 (candidate 0)
 
 I've created a candidate build for the first Apache release of ZooKeeper
 
 - version 3.0.0.
 
 *** Please download, test and VOTE before the
 *** vote closes EOD on Friday, October 24.***
 
 http://people.apache.org/~phunt/zookeeper-3.0.0-candidate-0/
 
 Patrick