Try using the logs, stat command or JMX to verify that each ZK server is
indeed a leader/follower as expected. You should have one leader and n-1
followers. Verify that you don't have any "standalone" servers (this is
the most frequent error I see - misconfiguration of a server such that
it thinks it's a standalone server; I often see where a user has 3
standalone servers which they think is a single quorum, all of the
servers will therefore be "inconsistent" to each other).
On 08/12/2010 05:42 PM, Ted Dunning wrote:
On Thu, Aug 12, 2010 at 4:57 PM, Dr Hao He<h...@softtouchit.com> wrote:
I am a little bit confused here. So, is the node inconsistency problem
that Vishal and I have seen here most likely caused by configurations or
If it is the former, I'd appreciate if you can point out where those silly
mistakes have been made and the correct way to embed ZK.
I think it is likely due to misconfiguration, but I don't know what the
issue is exactly. I think that another poster suggested that you ape the
normal ZK startup process more closely. That sounds good but it may be
incompatible with your goals of integrating all configuration into a single
XML file and not using the normal ZK configuration process.
Your thought about forking ZK is a good one since there are calls to
System.exit() that could wreak havoc.
Although I agree with your comments about the architectural issues that
embedding may lead to and we are aware of those, I do not agree that
embedding will always lead to those issues.
I agree that embedding won't always lead to those issues and your
application is a reasonable counter-example. As is common, I think that the
exception proves the rule since your system is really just another way to
launch an independent ZK cluster rather than an example of ZK being embedded
into an application.