[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ZooDiscovery without starting ANY ZooKeeper instance

Am 07.02.2011 16:28, schrieb ahmed.aadel@xxxxxxxxxxxxxxxxxx:
Hi Martin,

The sole existence of zoodiscovery.autoStart regardless of being (zoodiscovery.autoStart=false or zoodiscovery.autoStart=true) will instruct  zooDiscovery to look for the system property  "zoodiscovery.flavor" then start  and configures itself following that  flavor. If no flavor system property is found it defaults starting a local zooKeeper server and connecting to it(useless in most cases). Not auto-stating means you must remove the "zoodiscovery.autoStart" property.

If those system properties are set then you go and call  this code (from your previous email)
>IContainer container =
>ContainerFactory.getDefault().createContainer("ecf.discovery.zoodiscovery");
>ID target = container.getConnectNamespace().createInstance(
        new String[] {"zoodiscovery.flavor.centralized=" + ip});
>container.connect(target, null);


then you're just duplicating your work.  You  just do it one way or the other, not both. That is, by setting system properties (at least  "zoodiscovery.autoStart<no need to true or false>" and  "zoodiscovery.flavor=some flavor") or programmatically the way you did as in your code above.

zooDiscovery instances configured to run centrally ("zoodiscovery.flavor.centralized"),  will all start just a client  zooKeeper and connect to the one instance playing the central role. Only the zooDiscovery instance playing that central role will start a server zooKeeper. as explained in :
http://wiki.eclipse.org/Zoodiscovery

Thanks for this. I think this is not intuitive, why not have 'zoodiscovery.autoStart=false' doing just nothing?

Still this problem: If I start one Application A with 'flavor.centralized=own IP' (at the moment InetAddress.getLocalHost().getHostAddress()) and another TWO Applications B & C with 'flavor.centralized=IP of Application A', all of them are running on the same machine!

=> then services of B & C are mixed up. I think this is because of the shared 'dataDir' located in temp or because of mixed up IPs?

Thanks,

Martin