[
https://issues.apache.org/jira/browse/KAFKA-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14120664#comment-14120664
]
Guozhang Wang commented on KAFKA-686:
-------------------------------------
Thanks [~phargett] and [~viktortnk] for your patches.
A general thought is that we may probably want to go one step further to avoid
the brokers to be unnecessarily fallen into the bad state. One example I have
seen before is that a 0.7 consumer mistakenly writes to a 0.8 Zookeeper may
cause the controller to fail and the whole cluster in a bad state. To be more
specific, according to the ZK data structure:
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+data+structures+in+Zookeeper
1. The controller would log the error and "exclude" the information when
encounter error in parsing a) consumer offsets, b) admin paths since these data
can be written by clients or admin tools.
2. The controller would fail gracefully (i.e. log the error and shutdown the
server itself) when encounter error in parsing a) broker registration info, b)
controller epoch, c) controller registration, d) topic registration info, and
e) partition state info, since these data can only be written by the brokers
themselves.
3. The broker should fail gracefully when encounter error in parsing a)
partition state info.
Some other comments:
1. readDataMaybeNull is used in other places of ZkUtils and other classes, and
they may also be modified accordingly.
2. I am wondering does Exception.failAsValue exist in scala version 2.8/9 also?
We are planning to retire scala 2.8 support but have not finished yet.
Will you have time recently to continue working on this ticket?
> 0.8 Kafka broker should give a better error message when running against 0.7
> zookeeper
> --------------------------------------------------------------------------------------
>
> Key: KAFKA-686
> URL: https://issues.apache.org/jira/browse/KAFKA-686
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Jay Kreps
> Priority: Blocker
> Labels: newbie, patch
> Fix For: 0.8.2
>
> Attachments: KAFAK-686-null-pointer-fix.patch,
> KAFKA-686-null-pointer-fix-2.patch
>
>
> People will not know that the zookeeper paths are not compatible. When you
> try to start the 0.8 broker pointed at a 0.7 zookeeper you get a
> NullPointerException. We should detect this and give a more sane error.
> Error:
> kafka.common.KafkaException: Can't parse json string: null
> at kafka.utils.Json$.liftedTree1$1(Json.scala:20)
> at kafka.utils.Json$.parseFull(Json.scala:16)
> at
> kafka.utils.ZkUtils$$anonfun$getReplicaAssignmentForTopics$2.apply(ZkUtils.scala:498)
> at
> kafka.utils.ZkUtils$$anonfun$getReplicaAssignmentForTopics$2.apply(ZkUtils.scala:494)
> at
> scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:61)
> at scala.collection.immutable.List.foreach(List.scala:45)
> at
> kafka.utils.ZkUtils$.getReplicaAssignmentForTopics(ZkUtils.scala:494)
> at
> kafka.controller.KafkaController.initializeControllerContext(KafkaController.scala:446)
> at
> kafka.controller.KafkaController.onControllerFailover(KafkaController.scala:220)
> at
> kafka.controller.KafkaController$$anonfun$1.apply$mcV$sp(KafkaController.scala:85)
> at
> kafka.server.ZookeeperLeaderElector.elect(ZookeeperLeaderElector.scala:53)
> at
> kafka.server.ZookeeperLeaderElector.startup(ZookeeperLeaderElector.scala:43)
> at kafka.controller.KafkaController.startup(KafkaController.scala:381)
> at kafka.server.KafkaServer.startup(KafkaServer.scala:90)
> at
> kafka.server.KafkaServerStartable.startup(KafkaServerStartable.scala:34)
> at kafka.Kafka$.main(Kafka.scala:46)
> at kafka.Kafka.main(Kafka.scala)
> Caused by: java.lang.NullPointerException
> at
> scala.util.parsing.combinator.lexical.Scanners$Scanner.<init>(Scanners.scala:52)
> at scala.util.parsing.json.JSON$.parseRaw(JSON.scala:71)
> at scala.util.parsing.json.JSON$.parseFull(JSON.scala:85)
> at kafka.utils.Json$.liftedTree1$1(Json.scala:17)
> ... 16 more
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
