Thanks Phil Hargett and Viktor Taranenko 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:
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?