> 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? > > Guozhang Wang wrote: > 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?
I see. Let's say we change the zookeeper data version for one path and update the currentVersion. This will update the version of all other data in zookeeper even though the format for other data did not really change. I would like to avoid this, but what do you think? - Swapnil ----------------------------------------------------------- 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 > >
