[jira] Updated: (ZOOKEEPER-139) Create Enums for WatcherEvent's KeeperState and EventType

2008-09-16 Thread Mahadev konar (JIRA)

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

Mahadev konar updated ZOOKEEPER-139:


Status: Open  (was: Patch Available)

cancelling patch to address the above mentioned issue.

> Create Enums for WatcherEvent's KeeperState and EventType
> -
>
> Key: ZOOKEEPER-139
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-139
> Project: Zookeeper
>  Issue Type: Sub-task
>Affects Versions: 3.0.0
>Reporter: Jakob Homan
>Assignee: Jakob Homan
> Fix For: 3.0.0
>
> Attachments: ZOOKEEPER-139.patch, ZOOKEEPER-139.patch
>
>


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



[jira] Commented: (ZOOKEEPER-135) Fat jar build target

2008-09-16 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-135:


Forgot to mention - please remove @author tags from javadoc.

> Fat jar build target
> 
>
> Key: ZOOKEEPER-135
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-135
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: build
>Reporter: Benjamin Reed
>Assignee: Benjamin Reed
>Priority: Minor
> Attachments: ZOOKEEPER-135.patch
>
>
> For testing and experimentation purposes it would be nice to have everything 
> in a self contained executable jar file that you can plop down on a machine 
> and run.

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



[jira] Updated: (ZOOKEEPER-135) Fat jar build target

2008-09-16 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-135:
---

Status: Open  (was: Patch Available)

-1 on current patch. I really don't like putting "mainClasses" into conf and 
FatJar.java into the main src dir. It won't be clear to users what these files 
are and how/if they are related.

I do think that having this as a contrib would be fine though:

contrib/fatjar/...
contrib/fatjar/conf
contrib/fatjar/src/java/main/org/apache/...

which can contain your build.xml, mainClasses, farjar.java, etc...  and esp a 
README.txt that describes what this is and how to use it. 

I'd suggest changing the name too.


> Fat jar build target
> 
>
> Key: ZOOKEEPER-135
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-135
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: build
>Reporter: Benjamin Reed
>Assignee: Benjamin Reed
>Priority: Minor
> Attachments: ZOOKEEPER-135.patch
>
>
> For testing and experimentation purposes it would be nice to have everything 
> in a self contained executable jar file that you can plop down on a machine 
> and run.

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



[jira] Updated: (ZOOKEEPER-127) Use of non-standard election ports in config breaks services

2008-09-16 Thread Flavio Paiva Junqueira (JIRA)

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

Flavio Paiva Junqueira updated ZOOKEEPER-127:
-

Attachment: ZOOKEEPER-127.patch

This patch chenges the way we pass in the configuration file the port number 
used for leader election. It also changes the references to servers on 
QuorumCnxManager from InetAddress to their server ids. I have them changed the 
challenge mechanism to use the server id instead, simplifying the mechanism.

I have also implemented some of the modifications proposed in JIRA 140.

> Use of non-standard election ports in config breaks services
> 
>
> Key: ZOOKEEPER-127
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-127
> Project: Zookeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.0.0
>Reporter: Mark Harwood
>Assignee: Flavio Paiva Junqueira
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: mhPortChanges.patch, ZOOKEEPER-127.patch, 
> ZOOKEEPER-127.patch
>
>
> In QuorumCnxManager.toSend there is a call to create a connection as follows:
> channel = SocketChannel.open(new InetSocketAddress(addr, port));
> Unfortunately "addr" is the ip address of a remote server while "port" is the 
> electionPort of *this* server.
> As an example, given this configuration (taken from my zoo.cfg)
>   server.1=10.20.9.254:2881
>   server.2=10.20.9.9:2882
>   server.3=10.20.9.254:2883
> Server 3 was observed trying to make a connection to host 10.20.9.9 on port 
> 2883 and obviously failing.
> In tests where all machines use the same electionPort this bug would not 
> manifest itself.

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



Roadmap for ZooKeeper 3.0

2008-09-16 Thread Patrick Hunt
The ZooKeeper JIRA is up to date and a tentative date of 9/22/2008 for 
the 3.0 release has been set. You can see the roadmap here:


https://issues.apache.org/jira/browse/ZOOKEEPER?report=com.atlassian.jira.plugin.system.project:roadmap-panel

3.0 will be our first Apache release. As such the Java package structure 
has changed (com.yahoo -> org.apache) which will require some work to 
migrate user code from pre-3.0 to 3.0. There are a few additional 
"incompatible" changes that have been lumped into 3.0, we wanted to pull 
any such changes into this release so that going fwd we could more 
easily maintain b/w compatibility in the apis/data (ie break things 
once, which had to be done anyway for package struct). You can see these 
changes by checking the appropriate checkbox in the "findissues" section 
of the JIRA.


The release notes for 3.0 will contain a section detailing the 
migrations necessary when migrating from 2.2.1 to 3.0


If you have any questions please respond. Regards,

Patrick




[jira] Updated: (ZOOKEEPER-131) Old leader election can elect a dead leader over and over again

2008-09-16 Thread Patrick Hunt (JIRA)

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

Patrick Hunt updated ZOOKEEPER-131:
---

Assignee: Benjamin Reed

> Old leader election can elect a dead leader over and over again
> ---
>
> Key: ZOOKEEPER-131
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-131
> Project: Zookeeper
>  Issue Type: Bug
>  Components: leaderElection
>Reporter: Benjamin Reed
>Assignee: Benjamin Reed
> Attachments: ZOOKEEPER-131.patch
>
>
> I think there is a race condition that is probably easy to get into with the 
> old leader election and a large number of servers:
> 1) Leader dies
> 2) Followers start looking for a new leader before all Followers have 
> abandoned the Leader
> 3) The Followers looking for a new leader see votes of Followers still 
> following the (now dead) Leader and start voting for the dead Leader
> 4) The dead Leader gets reelected.
> For the old leader election a server should not vote for another server that 
> is not nominating himself.

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



[jira] Updated: (ZOOKEEPER-131) Old leader election can elect a dead leader over and over again

2008-09-16 Thread Benjamin Reed (JIRA)

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

Benjamin Reed updated ZOOKEEPER-131:


Attachment: ZOOKEEPER-131.patch

This patch adds a test case that reproduces the problem and a fix (that passes 
the test).

The fix simply removes votes for hosts that a peer has not heard from before 
the vote is counted.

> Old leader election can elect a dead leader over and over again
> ---
>
> Key: ZOOKEEPER-131
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-131
> Project: Zookeeper
>  Issue Type: Bug
>  Components: leaderElection
>Reporter: Benjamin Reed
> Attachments: ZOOKEEPER-131.patch
>
>
> I think there is a race condition that is probably easy to get into with the 
> old leader election and a large number of servers:
> 1) Leader dies
> 2) Followers start looking for a new leader before all Followers have 
> abandoned the Leader
> 3) The Followers looking for a new leader see votes of Followers still 
> following the (now dead) Leader and start voting for the dead Leader
> 4) The dead Leader gets reelected.
> For the old leader election a server should not vote for another server that 
> is not nominating himself.

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



[jira] Updated: (ZOOKEEPER-131) Old leader election can elect a dead leader over and over again

2008-09-16 Thread Benjamin Reed (JIRA)

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

Benjamin Reed updated ZOOKEEPER-131:


Status: Patch Available  (was: Open)

> Old leader election can elect a dead leader over and over again
> ---
>
> Key: ZOOKEEPER-131
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-131
> Project: Zookeeper
>  Issue Type: Bug
>  Components: leaderElection
>Reporter: Benjamin Reed
> Attachments: ZOOKEEPER-131.patch
>
>
> I think there is a race condition that is probably easy to get into with the 
> old leader election and a large number of servers:
> 1) Leader dies
> 2) Followers start looking for a new leader before all Followers have 
> abandoned the Leader
> 3) The Followers looking for a new leader see votes of Followers still 
> following the (now dead) Leader and start voting for the dead Leader
> 4) The dead Leader gets reelected.
> For the old leader election a server should not vote for another server that 
> is not nominating himself.

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



[jira] Commented: (ZOOKEEPER-63) Race condition in client close() operation

2008-09-16 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-63:
---

Thank you for taking the time to report the issue. Regards.

> Race condition in client close() operation
> --
>
> Key: ZOOKEEPER-63
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-63
> Project: Zookeeper
>  Issue Type: Bug
>  Components: java client
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Attachments: client-test-fail.diff, ZOOKEEPER-63.patch
>
>
> There is a race condition in the java close operation on ZooKeeper.java.
> Client is sending a disconnect request to the server. Server will close any 
> open connections with the client when it receives this. If the client has not 
> yet shutdown it's subthreads (event/send threads for example) these threads 
> may consider the condition an error. We see this alot in the tests where the 
> clients output error logs because they are unaware that a disconnection has 
> been requested by the client.
> Ben mentioned: perhaps we just have to change state to closed (on client) 
> before sending disconnect request.

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



[jira] Commented: (ZOOKEEPER-140) Deadlock in QuorumCnxManager

2008-09-16 Thread Patrick Hunt (JIRA)

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

Patrick Hunt commented on ZOOKEEPER-140:


Flavio, could you update the server java code with a summary of this JIRA as a 
comment? Perhaps as part of a class javadoc so that it will show up in the 
generated javadoc html.

> Deadlock in QuorumCnxManager
> 
>
> Key: ZOOKEEPER-140
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-140
> Project: Zookeeper
>  Issue Type: Bug
>Reporter: Flavio Paiva Junqueira
>
> Frequently the servers deadlock in QuorumCnxManager:initiateConnection on
> s.read(msgBuffer) when reading the challenge from the peer.
> Calls to initiateConnection and receiveConnection are synchronized, so only 
> one or the other can be executing at a time. This prevents two connections 
> from opening between the same pair of servers.
> However, it seems that this leads to deadlock, as in this scenario:
> {noformat}
> A (initiate --> B)
> B (initiate --> C)
> C (initiate --> A)
> {noformat}
> initiateConnection can only complete when receiveConnection runs on the 
> remote peer and answers the challenge. If all servers are blocked in 
> initiateConnection, receiveConnection never runs and leader election halts.

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



[jira] Commented: (ZOOKEEPER-139) Create Enums for WatcherEvent's KeeperState and EventType

2008-09-16 Thread Mahadev konar (JIRA)

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

Mahadev konar commented on ZOOKEEPER-139:
-

i forgot to mention that the changes to the jute file would require changes to 
the c code... can we just change the wrapper name class instead of chanhing the 
c code 

> Create Enums for WatcherEvent's KeeperState and EventType
> -
>
> Key: ZOOKEEPER-139
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-139
> Project: Zookeeper
>  Issue Type: Sub-task
>Affects Versions: 3.0.0
>Reporter: Jakob Homan
>Assignee: Jakob Homan
> Fix For: 3.0.0
>
> Attachments: ZOOKEEPER-139.patch, ZOOKEEPER-139.patch
>
>


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