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 h...@softtouchit.com http://softtouchit.com http://itunes.com/apps/Scanmobile 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. >>