Well, may be you can run multiple ZK server instances, overlaying them on the same hardware.
Jun On Wed, Oct 19, 2011 at 1:02 PM, Mathias Herberts < mathias.herbe...@gmail.com> wrote: > Not using a chroot is not a feasible thing when the ZK ensemble is > shared by several Kafka clusters. > > On Wed, Oct 19, 2011 at 21:54, Jun Rao <jun...@gmail.com> wrote: > > This particular ZK issue only exposes if the ZK connect string uses > chroot > > and there is a ZK disconnect. In the near term, you can choose not to use > > chroot in your ZK connect string. > > > > Thanks, > > > > Jun > > > > On Wed, Oct 19, 2011 at 12:30 PM, Dan Brown <d...@metamx.com> wrote: > > > >> On Tue, Oct 18, 2011 at 15:02, Mathias Herberts > >> <mathias.herbe...@gmail.com> wrote: > >> >> I think Jun or Neha had tracked this one down at LinkedIn and it is > >> actually > >> >> a zk bug. I think it is this one, but they could confirm: > >> >> > >> >> https://issues.apache.org/jira/browse/ZOOKEEPER-961 > >> > > >> > Sure looks like it. > >> > >> Confirmed. Running the above repro against zookeeper trunk produces a > >> responsive consumer that successfully rebalances when the broker > >> rejoins. > >> > >> > So besides waiting for ZK 3.3.4 there is not much that can be done > >> > since Kafka does not offer a way to change the root znode of a > >> > cluster. > >> > >> Yeah, it's unclear that zk-3.3.4 will release anytime soon. Instead of > >> relying on zk chroot, why not just expose the zk paths as config > >> parameters for consumers, brokers, and producers? > >> > >> object ZkUtils { > >> val ConsumersPath = "/consumers" > >> val BrokerIdsPath = "/brokers/ids" > >> val BrokerTopicsPath = "/brokers/topics" > >> ... > >> > > >
