> On April 25, 2014, 6:35 p.m., Joel Koshy wrote: > > core/src/main/scala/kafka/server/KafkaServerStartable.scala, line 55 > > <https://reviews.apache.org/r/20718/diff/1/?file=568568#file568568line55> > > > > Unused
This is actually exposed setting custom state that is not one of the defined enums. One example is for our internal custom kafka server startable override can allow more states that is not defined in BrokerStates. The alternative is to just come up with all possible enums and let that be the only option available, but I was thinking that might be a bit too limiting. I'm not sure if this approach is too permissive either, you have more thoughts? > On April 25, 2014, 6:35 p.m., Joel Koshy wrote: > > core/src/main/scala/kafka/server/BrokerStates.scala, line 28 > > <https://reviews.apache.org/r/20718/diff/1/?file=568566#file568566line28> > > > > Just a thought: I'm wondering if it is better to have a bit-vector > > approach for states; although that will limit the number of possible states > > - but I think that is fine. > > > > The main reason for this is that it will enable composing simultaneous > > states. E.g., in this approach you cannot distinguish state 5 from state 3 > > (if a shutting down broker is the controller). Although we can probably > > infer that from the fact that the other brokers are likely in state (2) or > > by looking at the active controller count separately. Still, we currently > > allow more than one broker to shut down. > > > > It also _might_ help catch erroneous dual states (due to bugs). > > > > What you have is probably fine for lifecycle states (except for the > > above caveat). However, if we ever want to allow more-than-lifecycle states > > (e.g., under-replicated is a state we _might_ want to include on this - > > even though we have a separate URP mbean and it's not a lifecycle state; > > another example is "loading consumer offsets"). Erroneous dual states is something I thought of, especially when state changes rapidly it will be harder to detect. The down side of having a bit field is also that you need to then also have to unset that state when you're going into another lifecycle state. I think coming back to the high level of what we want for broker states, since really a broker should really just be in a state at one point of time, setting a particular state I think makes more sense. Composite states probably makes more sense for different component states. - Timothy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20718/#review41501 ----------------------------------------------------------- On April 25, 2014, 5:25 p.m., Timothy Chen wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/20718/ > ----------------------------------------------------------- > > (Updated April 25, 2014, 5:25 p.m.) > > > Review request for kafka. > > > Bugs: KAFKA-1384 > https://issues.apache.org/jira/browse/KAFKA-1384 > > > Repository: kafka > > > Description > ------- > > KAFKA-1384: Logging kafka state metric > > > Diffs > ----- > > core/src/main/scala/kafka/controller/KafkaController.scala > 933de9dd324c7086efe6aa610335ef370d9e9c12 > core/src/main/scala/kafka/log/Log.scala > 46df8d99d977a3b010a9b9f4698187fa9bfb2498 > core/src/main/scala/kafka/log/LogManager.scala > ac67f081e6219fd2181479e7a2bb88ea6044e6cc > core/src/main/scala/kafka/server/BrokerStates.scala PRE-CREATION > core/src/main/scala/kafka/server/KafkaServer.scala > c208f83bed7fb91f07fae42f2b66892e6d46fecc > core/src/main/scala/kafka/server/KafkaServerStartable.scala > acda52b801714bcc182edc0ced925f0e4b493fc1 > > Diff: https://reviews.apache.org/r/20718/diff/ > > > Testing > ------- > > > Thanks, > > Timothy Chen > >
