> On Nov. 19, 2013, 5:21 p.m., Guozhang Wang wrote: > > core/src/main/scala/kafka/server/ZookeeperLeaderElector.scala, line 52 > > <https://reviews.apache.org/r/15665/diff/3/?file=388317#file388317line52> > > > > Can we make the version number a global variable, so that when we > > upgrade in the future we only need to upgrade in once place? > > Swapnil Ghike wrote: > My understanding was that the code may evolve to deal with situations > wherein we have some zookeeper paths that are on version n, and others are on > version n' and some more are on version n''. To make this explicit, I wonder > if it makes sense to let each zookeeper path have its own version value and > not put any global value that everyone else refers to. > > But I could be wrong, comments?
Probably I did not make it clear, I was suggesting we put a currentVersion in the kafka code, and use this variable for all writes in ZK, for reads from ZK, we may need a swtich/case for different versions. How does that sound? - Guozhang ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15665/#review29116 ----------------------------------------------------------- On Nov. 19, 2013, 3:21 a.m., Swapnil Ghike wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/15665/ > ----------------------------------------------------------- > > (Updated Nov. 19, 2013, 3:21 a.m.) > > > Review request for kafka. > > > Bugs: KAFKA-1135 > https://issues.apache.org/jira/browse/KAFKA-1135 > > > Repository: kafka > > > Description > ------- > > iteration 2 > > > json.encode > > > Diffs > ----- > > core/src/main/scala/kafka/admin/AdminUtils.scala > 8ff4bd5a5f6ea1a51df926c31155251bcc109238 > core/src/main/scala/kafka/admin/PreferredReplicaLeaderElectionCommand.scala > 26beb9698422ceb6cc682b86913b4f9d2d4f1307 > core/src/main/scala/kafka/api/LeaderAndIsrRequest.scala > 981d2bbecf2fa11f1d2c423535c7c30851d2d7bb > core/src/main/scala/kafka/consumer/TopicCount.scala > a3eb53e8262115d1184cd1c7a2b47f21c22c077b > core/src/main/scala/kafka/consumer/ZookeeperConsumerConnector.scala > c0350cd05cf1b59866a1fedccbeb700b3e828d44 > core/src/main/scala/kafka/controller/KafkaController.scala > 88792c2b2a360e928ab9cd00de151e5d5f94452d > core/src/main/scala/kafka/server/ZookeeperLeaderElector.scala > 33b73609b1178c56e692fb60e35aca04ad1af586 > core/src/main/scala/kafka/utils/Utils.scala > c9ca95f1937d0ef2e64c70e4d811a0d4f358d9db > core/src/main/scala/kafka/utils/ZkUtils.scala > 856d13605b0b4bf86010571eacbacc0fb0ba7950 > > Diff: https://reviews.apache.org/r/15665/diff/ > > > Testing > ------- > > Verified that zookeeper data looks like the structures defined in > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+data+structures+in+Zookeeper > > > Thanks, > > Swapnil Ghike > >
