You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Ryan P (JIRA)" <ji...@apache.org> on 2017/01/06 19:38:58 UTC
[jira] [Created] (KAFKA-4606) make getOffsetsTopicPartitionCount
mutable
Ryan P created KAFKA-4606:
-----------------------------
Summary: make getOffsetsTopicPartitionCount mutable
Key: KAFKA-4606
URL: https://issues.apache.org/jira/browse/KAFKA-4606
Project: Kafka
Issue Type: Improvement
Components: consumer
Reporter: Ryan P
Under certain circumstances users may wish to increase the size of their __consumer_offsets topic to spread the load as their consumer load increases.
The current limitation, in which we try to prevent the topic's expansion makes this incredibly difficult. This is done intentionally to reduce the risk of unexpected behavior once the group id has been assigned a new coordinator.
Instead Kafka should consider ways to handle this operation more gracefully with the following behaviors.
1. Calculate the number of __consumer_offsets partitions from the metadata cache with each metadata update
2. Force a rebalance after the new partitions are added to the topic. *I'm sure to take into consideration here as well. Alternatively the operation could be documented as risky emphasizing the behavior of the reset policy under these conditions.
Currently the number of partitions for the consumer_offsets topic is fixed. This mean you will need to restart each broker to ensure that coordinator discovery happens as expected. That seems less than ideal to me for what seems to be a fairly artificial limitation of the consumer group implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)