> On July 7, 2015, 2:18 a.m., Jun Rao wrote: > > Thanks for the patch. A few more comments below. > > > > 1. The patch doesn't apply. Could you rebase? > > 2. Also, we need the logic to read all existing client configs. Is that in > > a separate jira? > > Aditya Auradkar wrote: > 1. Will do. > 2. Hey Jun - I didn't understand what you meant by "read all existing > client configs". Can you elaborate? In general, I'm submitting all followup > client config changes in subsequent patches to avoid making the patches too > large. This patch will basically refactor the code and make it possible to > receive client change notifications.
2. When starting up a broker, we need to read all existing client configs into ClientIdConfigHandler, right? - Jun ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34554/#review90622 ----------------------------------------------------------- On July 8, 2015, 2:14 a.m., Aditya Auradkar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34554/ > ----------------------------------------------------------- > > (Updated July 8, 2015, 2:14 a.m.) > > > Review request for kafka, Joel Koshy and Jun Rao. > > > Bugs: KAFKA-2205 > https://issues.apache.org/jira/browse/KAFKA-2205 > > > Repository: kafka > > > Description > ------- > > KAFKA-2205: Summary of changes > 1. Generalized TopicConfigManager to DynamicConfigManager. It is now able to > handle multiple types of entities. > 2. Changed format of the notification znode as described in KIP-21 > 3. Replaced TopicConfigManager with DynamicConfigManager. > 4. Added new testcases. Existing testcases all pass > 5. Added ConfigCommand to handle all config changes. Eventually this will > make calls to the broker once the new API's are built for now it speaks to ZK > directly > 6. Addressed all of Jun's comments. > > > Diffs > ----- > > core/src/main/scala/kafka/admin/AdminUtils.scala > f06edf41c732a7b794e496d0048b0ce6f897e72b > core/src/main/scala/kafka/admin/ConfigCommand.scala PRE-CREATION > core/src/main/scala/kafka/admin/TopicCommand.scala > a2ecb9620d647bf8f957a1f00f52896438e804a7 > core/src/main/scala/kafka/cluster/Partition.scala > 2649090b6cbf8d442649f19fd7113a30d62bca91 > core/src/main/scala/kafka/controller/KafkaController.scala > 20f1499046c768adbcd2bf8ad5969589c8641f34 > core/src/main/scala/kafka/controller/PartitionLeaderSelector.scala > bb6b5c8764522e7947bb08998256ce1deb717c84 > core/src/main/scala/kafka/controller/TopicDeletionManager.scala > 64ecb499f24bc801d48f86e1612d927cc08e006d > core/src/main/scala/kafka/server/ConfigHandler.scala PRE-CREATION > core/src/main/scala/kafka/server/KafkaServer.scala > 18917bc4464b9403b16d85d20c3fd4c24893d1d3 > core/src/main/scala/kafka/server/ReplicaFetcherThread.scala > c89d00b5976ffa34cafdae261239934b1b917bfe > core/src/main/scala/kafka/server/TopicConfigManager.scala > 01b1b0a8efe6ab3ddc7bf9f1f535b01be4e2e6be > core/src/main/scala/kafka/utils/ZkUtils.scala > 166814c2959a429e20f400d1c0e523090ce37d91 > core/src/test/scala/unit/kafka/admin/AdminTest.scala > 252ac813c8df1780c2dc5fa9e698fb43bb6d5cf8 > core/src/test/scala/unit/kafka/admin/ConfigCommandTest.scala PRE-CREATION > core/src/test/scala/unit/kafka/admin/TopicCommandTest.scala > dcd69881445c29765f66a7d21d2d18437f4df428 > core/src/test/scala/unit/kafka/server/DynamicConfigChangeTest.scala > 8a871cfaf6a534acd1def06a5ac95b5c985b024c > > Diff: https://reviews.apache.org/r/34554/diff/ > > > Testing > ------- > > 1. Added new testcases for new code. > 2. Verified that both topic and client configs can be changed dynamically by > starting a local cluster > > > Thanks, > > Aditya Auradkar > >
