[
https://issues.apache.org/jira/browse/KAFKA-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16523146#comment-16523146
]
Narayan Periwal edited comment on KAFKA-7026 at 6/26/18 4:01 AM:
-----------------------------------------------------------------
[~vahid], Can this issue be there with RangeAssignor as well, because we have
seen this issue occuring multiple time in our Kafka consumer (0.10.2.1) with
RangeAssignor. Jira - KAFKA-6681.
Some observation is that there is spike in the number of UnderReplicated
partition in our Kafka cluster, after which multiple consumer instances start
consuming the same topic partition.
Kafka broker is also at version 0.10.2.1
was (Author: nperiwal):
[~vahid], Can this issue be there with RangeAssignor as well, because we have
seen this issue occuring multiple time in our Kafka consumer (0.10.2.1) with
RangeAssignor. Jira - KAFKA-6681.
Some observation is that there is spike in the number of UnderReplicated
partition, after which multiple consumer instances start consuming the same
topic partition
> Sticky assignor could assign a partition to multiple consumers
> --------------------------------------------------------------
>
> Key: KAFKA-7026
> URL: https://issues.apache.org/jira/browse/KAFKA-7026
> Project: Kafka
> Issue Type: Bug
> Components: clients
> Reporter: Vahid Hashemian
> Assignee: Vahid Hashemian
> Priority: Major
>
> In the following scenario sticky assignor assigns a topic partition to two
> consumers in the group:
> # Create a topic {{test}} with a single partition
> # Start consumer {{c1}} in group {{sticky-group}} ({{c1}} becomes group
> leader and gets {{test-0}})
> # Start consumer {{c2}} in group {{sticky-group}} ({{c1}} holds onto
> {{test-0}}, {{c2}} does not get any partition)
> # Pause {{c1}} (e.g. using Java debugger) ({{c2}} becomes leader and takes
> over {{test-0}}, {{c1}} leaves the group)
> # Resume {{c1}}
> At this point both {{c1}} and {{c2}} will have {{test-0}} assigned to them.
>
> The reason is {{c1}} still has kept its previous assignment ({{test-0}}) from
> the last assignment it received from the leader (itself) and did not get the
> next round of assignments (when {{c2}} became leader) because it was paused.
> Both {{c1}} and {{c2}} enter the rebalance supplying {{test-0}} as their
> existing assignment. The sticky assignor code does not currently check and
> avoid this duplication.
>
> Note: This issue was originally reported on
> [StackOverflow|https://stackoverflow.com/questions/50761842/kafka-stickyassignor-breaking-delivery-to-single-consumer-in-the-group].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
