I created the first version of such class in the last patch for https://issues.apache.org/jira/browse/ZOOKEEPER-784
One good thing to have in such class is peers partitioning. E.g. for 5-peers ensemble, emulate a situation when 3 peers are in one datacenter, 2 are in another, and datacenters become partitioned. However this doesn't look easy. One solution is to abstract networking code (leader-learner communication and leader election) and inject rules like "if i'm from datacenter 1, i'm not talking to datacenter 2" for testing. I also posted generalized version of this question to stackoverflow: http://bit.ly/clpq7u Do you have some thoughts on how to better implement this? On Fri, Jun 25, 2010 at 10:12 PM, Patrick Hunt <ph...@apache.org> wrote: > Sounds like a good idea to me, improving our ability to test quorum > configurations would be great. > > Patrick > > > On 06/23/2010 11:46 AM, Sergey Doroshenko wrote: > >> While incorporating tests for read-only mode, I found I don't like how >> QuorumBase, the main utility for quorum testing, is made -- it has 5 >> fields >> for 5 QuorumPeers, also 5 fields for ports, 5 fields for directories. In >> general, it's very inflexible (you can't easily shutdown particular peer >> and >> then bring up, etc) and hard-coded. >> >> I think it would be nice to create a class which would setup 2n+1 peers, >> and >> it would be possible to start/stop all peers / particular peer / n+1 peers >> etc. And make QuorumBase particular case of this class with n=2. >> >> What do you think? >> >> -- Regards, Sergey
