hi, Ted,

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 
any difference.  

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
>> suggest
>> to take an approach of having an API to support embedded ZK instead of
>> asking users to not embed ZK.

Reply via email to