New consumer API
What is a
TopicFilter can be either a whitelist or a blacklist. e.g.,
- Example of a whitelist
- Example of a blacklist
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
KafkaStream[T]'s iterator is a
ConsumerIterator[T] which is an iterator over
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
createMessageStreamsByFilterAPI as well.
- It may be possible to combine the
createMessageStreamsByFiltercalls into one API. This would need to be fleshed out in some detail, but we could have a higher-level
Topicclass that can either be a static topic, or a
TopicFilter. Another advantage of this is that the high-level
Topicclass 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
createMessageStreamscall 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
createMessageStreamson the same connector object. For example, the
consumerIdStringis 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: