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" >> ... >> >
