Adding a manual override path in the config seems like an acceptable thing to do, but it is not clear we will get 0.8 out before zookeeper gets their next release out. Would this have any use other than working around this zk problem?
-Jay 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" > >> ... > >> > > >
