Hadoop QA commented on ZOOKEEPER-498:

+1 overall.  Here are the results of testing the latest attachment 
  against trunk revision 802108.

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

    +1 tests included.  The patch appears to include 6 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: 
Findbugs warnings: 
Console output: 

This message is automatically generated.

> Unending Leader Elections : WAN configuration
> ---------------------------------------------
>                 Key: ZOOKEEPER-498
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-498
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: leaderElection
>    Affects Versions: 3.2.0
>         Environment: Each machine:
> CentOS 5.2 64-bit
> 2GB ram
> java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed 
> Network Topology:
> DC : central data center
> POD(N): remote data center
> Zookeeper Topology:
> Leaders may be elected only in DC (weight = 1)
> Only followers are elected in PODS (weight = 0)
>            Reporter: Todd Greenwood-Geer
>            Assignee: Flavio Paiva Junqueira
>            Priority: Critical
>             Fix For: 3.2.1, 3.3.0
>         Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, 
> zk498-test.tar.gz, zoo.cfg, ZOOKEEPER-498.patch, ZOOKEEPER-498.patch, 
> ZOOKEEPER-498.patch
> In a WAN configuration, ZooKeeper is endlessly electing, terminating, and 
> re-electing a ZooKeeper leader. The WAN configuration involves two groups, a 
> central DC group of ZK servers that have a voting weight = 1, and a group of 
> servers in remote pods with a voting weight of 0.
> What we expect to see is leaders elected only in the DC, and the pods to 
> contain only followers. What we are seeing is a continuous cycling of 
> leaders. We have seen this consistently with 3.2.0, 3.2.0 + recommended 
> patches (473, 479, 481, 491), and now release 3.2.1.

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

Reply via email to