Patrick Hunt commented on ZOOKEEPER-498:

Looks to me like 0 weight is still busted, fle0weighttest is actually failing 
on my machine, however it's reported as success:
------------- Standard Error -----------------
Exception in thread "Thread-108" junit.framework.AssertionFailedError: Elected 
zero-weight server
    at junit.framework.Assert.fail(Assert.java:47)
------------- ---------------- ---------------

this is probably due because the test is calling assert in a thread other than 
the main test thread - which junit will not track/knowabout.

One problem I see with these tests (0weight test I looked at) -- it doesn't 
have a client attempt to connect to the various servers as part of declaring 
success. Really we should only consider "success"ful test (ie assert that) if a 
client can connect to each server in the cluster and change/seechanges. As part 
of fixing this we really need to do a sanity check by testing the various 
command lines and checking that a client can connect.

I'm not even sure FLEnewepochtest/fletest/etc... are passing either. new epoch 
seems to just thrash...

Also I tried 3 & 5 server quorums "by hand from the command line" with 0 weight 
and they see similar issues to what Todd is seeing.

this is happening for me on both the trunk and 3.2 branch source.

> 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: Patrick Hunt
>            Priority: Critical
>             Fix For: 3.2.1, 3.3.0
>         Attachments: dc-zook-logs-01.tar.gz, pod-zook-logs-01.tar.gz, zoo.cfg
> 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