Child pages
  • Consumer API changes
Skip to end of metadata
Go to start of metadata

New consumer API


What is a TopicFilter?

TopicFilter can be either a whitelist or a blacklist. e.g.,

  • Example of a whitelist TopicFilter: new Whitelist("white.*")
  • Example of a blacklist TopicFilter: new Blacklist("black.*")

Although Java regex allows you to specify anything with a single regex (i.e., you don't really need a blacklist option per se), negating a whitelist in Java regex is clumsy. It is convenient to be able to easily specify a whitelist and blacklist. Although right now TopicFilter supports only one of whitelist/blacklist in future we may want to support a chain of filters to do more elaborate topic selection.

What is a MessageAndMetadata?

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:


  • Simpler, more intuitive API which is consistent with the createMessageStreamsByFilter API as well.
  • 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.


  • The above also reveals an advantage of creating multiple streams for multiple topics at one-shot . 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 (which receives atopic-count-map), only one rebalance (for all topics) will be required.
  • Not a disadvantage, but additional work: the consumer connector code is currently broken with respect to supporting multiple calls to createMessageStreams on the same connector object. For example, the consumerIdString is per connector object, and not per call. There are a bunch of other global variables that may need to become per-call instances. Anyway, the point is that we would need to completely fix that if we want to deprecate the option to provide a topic-count-map.

Impact to clients

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

will change to:

Existing API


  2. Mailing list discussion
  • No labels