Page History

...

The {{KafkaStream\[T\]}}'s iterator is a {{ConsumerIterator\[T\]}} which is an iterator over {{MessageAndMetadata\[T\]}} objects.

Can we eliminate the need for two methods in the API? Also, providing a topic-count-map in the createMessageStreams API is burdensome. Can we get rid of that?

If we don't support the one-shot approach of creating multiple streams for multiple topics, then the most obvious alternative is:

  def createMessageStreams[T](topic: String, numStreams: Int,
                              decoder: Decoder[T] = new DefaultDecoder)
    : Seq[KafkaStream[T]]

The above also reveals an advantage of creating multiple streams for multiple topics at one-shot (by providing the topic-count-map). If you want to create multiple streams for multiple topics, then you would need to make a createMessageStreams call for each topic, which would trigger one rebalance for each topic. With the one-shot call, only one rebalance (for all topics) will be required.

On the other hand, the above also suggests that it may be possible to combine the createMessageStreams and createMessageStreamsByFilter calls into one API. This would need to be fleshed out in some detail, but we could have a higher-level Topic class that can either be a static topic, or a TopicFilter. Another advantage of this is that the high-level Topic class it could do things like validate topic names. However, the consumer code would need to explicitly call new Topic(new Whitelist("white.*") or new Topic("topicname") but that does not seem so bad.

Impact to clients

Client code will need to change, since the current pattern of:

...