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 embedding?
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.
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. In our case, we have a very simple
orchestration framework that starts various services according to our XML
configuration file since we need to start them in the right sequence.
Architecturally, this is just like writing a set of unix scripts to start ZK
and other services. The only difference is that we happen to implement it in
Java and XML. In short, services coordinated by ZK do not embed ZK, the top
level orchestration layer does. The only potential problem I see here is that
we are running all those services in one JVM but this can be easily changed.
We are going to try to fork out ZK in a separate JVM that and see if it makes
Dr Hao He
XPE - the truly SOA platform
On 13/08/2010, at 8:25 AM, Ted Dunning wrote:
> I am not saying that the API shouldn't support embedded ZK.
> I am just saying that it is almost always a bad idea. It isn't that I am
> asking you to not do it, it is just that I am describing the experience I
> have had and that I have seen others have. In a nutshell, embedding leads
> to problems and it isn't hard to see why.
> On Thu, Aug 12, 2010 at 3:02 PM, Vishal K <vishalm...@gmail.com> wrote:
>> 2. With respect to Ted's point about backward compatibility, I would
>> to take an approach of having an API to support embedded ZK instead of
>> asking users to not embed ZK.