On Fri, Jul 24, 2009 at 4:23 PM, Todd Greenwood <to...@audiencescience.com>wrote:
> Could you explain the idea behind the Observers feature, what this > concept is supposed to address, and how it applies to the WAN > configuration problem in particular? > Not really. I am just echoing comments on observers from them that know. > """ > The ideas for federating ZK or allowing observers would likely do what > you > want. I can imagine that an observer would only care that it can see > it's > local peers and one of the observers would be elected to get updates > (and > thus would care about the central service). > """ > This certainly sounds like exactly what I want...Was this introduced in > 3.2 in full, or only partially? > I don't think it is even in trunk yet. Look on Jira or at the recent logs of this mailing list. > > Here, do you mean the servers will log warnings untill all the ensemble > members are visible to each other? > Again, I can only speculate. I would guess if a quorum of sibling observers is not available, ZK servers freeze all changes but continue to serve read-only. > Given that 3.2 has a serious bug, I've recommended that we proceed with > our deploy based 3.1.1. For this version, it sounds like we will have to > open up connectivity from each zk server to each zk server, across the > various zones in the WAN. Is this correct? > I don't think so. I think you would be ahead if you put all ZK machines in the central zone and only have WAN connections between clients and servers, not from server to server. Otherwise, all clients pay for the geographical sins of a few. -- Ted Dunning, CTO DeepDyve
