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
