[jira] [Comment Edited] (KAFKA-7026) Sticky assignor could assign a partition to multiple consumers (KIP-341)
[
https://issues.apache.org/jira/browse/KAFKA-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932965#comment-16932965
]
redbrick9 edited comment on KAFKA-7026 at 9/19/19 1:20 AM:
---
We are testing our application based on kafka, when we are using iptables to
drop/reject packets from consumers to broker for the network issues'
similation. We ran into the similiar problem.
A few partitions were assigned to the more than one consumers.
We are using kafka 2.3.0 and StickyAssignor assignment strategy. It looks good
to us to use another assignment strategy.
It is easy to reproduce. Just adding rules to reject/drop packets from consumer
then delete the rules. We can see the following output.
{code:java}
bin/kafka-consumer-groups.sh --bootstrap-server 172.93.57.21:9092 --group
test-group --describe GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG
CONSUMER-ID HOST CLIENT-ID test-group test-topic 12 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 2 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 5 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 15 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 3 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 8 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 7 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 5 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 4 - 0 -
consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320 /172.93.57.23 consumer-1
test-group test-topic 11 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 0 - 0 -
consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320 /172.93.57.23 consumer-1
test-group test-topic 3 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 10 - 0 -
consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320 /172.93.57.23 consumer-1
test-group test-topic 6 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 12 - 0 -
consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b /172.93.57.21 consumer-1
test-group test-topic 2 - 0 - consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b
/172.93.57.21 consumer-1 test-group test-topic 14 - 0 -
consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b /172.93.57.21 consumer-1
test-group test-topic 1 - 0 - consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b
/172.93.57.21 consumer-1 test-group test-topic 13 - 0 -
consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b /172.93.57.21 consumer-1
test-group test-topic 7 - 0 - consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b
/172.93.57.21 consumer-1 test-group test-topic 9 - 0 -
consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b /172.93.57.21 consumer-1
{code}
I'm not sure if this is same problem. Could you help take a look at it? Thanks.
was (Author: redbrick9):
We are testing our application based on kafka, when we are using iptables to
drop/reject packets from consumers to broker for the network issues'
similation. We ran into the similiar problem.
A few partitions were assigned to the more than one consumers.
We are using kafka 2.3.0 and StickyAssignor assignment strategy. It looks good
to us to use another assignment strategy.
It is easy to reproduce. Just adding rules to reject/drop packets from consumer
then delete the rules. We can see the following output.
{code:java}
bin/kafka-consumer-groups.sh --bootstrap-server 172.93.57.21:9092 --group
test-group --describe GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG
CONSUMER-ID HOST CLIENT-ID test-group test-topic 12 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 2 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 5 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 15 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 3 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 8 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 7 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 5 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 4 - 0 -
consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320 /172.93.57.23 consumer-1
test-group test-top
[jira] [Comment Edited] (KAFKA-7026) Sticky assignor could assign a partition to multiple consumers (KIP-341)
[
https://issues.apache.org/jira/browse/KAFKA-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932965#comment-16932965
]
redbrick9 edited comment on KAFKA-7026 at 9/19/19 1:19 AM:
---
We are testing our application based on kafka, when we are using iptables to
drop/reject packets from consumers to broker for the network issues'
similation. We ran into the similiar problem.
A few partitions were assigned to the more than one consumers.
We are using kafka 2.3.0 and StickyAssignor assignment strategy. It looks good
to us to use another assignment strategy.
It is easy to reproduce. Just adding rules to reject/drop packets from consumer
then delete the rules. We can see the following output.
{code:java}
bin/kafka-consumer-groups.sh --bootstrap-server 172.93.57.21:9092 --group
test-group --describe GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG
CONSUMER-ID HOST CLIENT-ID test-group test-topic 12 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 2 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 5 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 15 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 3 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 8 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 7 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 5 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 4 - 0 -
consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320 /172.93.57.23 consumer-1
test-group test-topic 11 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 0 - 0 -
consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320 /172.93.57.23 consumer-1
test-group test-topic 3 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 10 - 0 -
consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320 /172.93.57.23 consumer-1
test-group test-topic 6 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 12 - 0 -
consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b /172.93.57.21 consumer-1
test-group test-topic 2 - 0 - consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b
/172.93.57.21 consumer-1 test-group test-topic 14 - 0 -
consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b /172.93.57.21 consumer-1
test-group test-topic 1 - 0 - consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b
/172.93.57.21 consumer-1 test-group test-topic 13 - 0 -
consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b /172.93.57.21 consumer-1
test-group test-topic 7 - 0 - consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b
/172.93.57.21 consumer-1 test-group test-topic 9 - 0 -
consumer-1-a5684c45-859c-4718-aa27-32fcf8f9c64b /172.93.57.21 consumer-1
{code}
was (Author: redbrick9):
We are testing our application based on kafka, when we are using iptables to
drop/reject packets from consumers to broker for the network issues'
similation. We ran into the similiar problem.
A few partitions were assigned to the more than one consumers.
We are using kafka 2.3.0 and StickyAssignor assignment strategy. It looks good
to us to use another assignment strategy.
It is easy to reproduce. Just adding rules to reject/drop packets from consumer
then delete the rules. We can see the following output.
{code:java}
// code placeholder
{code}
bin/kafka-consumer-groups.sh --bootstrap-server 172.93.57.21:9092 --group
test-group --describe GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG
CONSUMER-ID HOST CLIENT-ID test-group test-topic 12 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 2 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 5 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 15 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 3 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 8 - 0 - consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682
/172.93.57.22 consumer-1 test-group test-topic 7 - 0 -
consumer-1-f94c41a7-a64c-4f22-bfa2-86b369f22682 /172.93.57.22 consumer-1
test-group test-topic 5 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320
/172.93.57.23 consumer-1 test-group test-topic 4 - 0 -
consumer-1-75e1a353-cd34-4e49-b88f-2e8da3117320 /172.93.57.23 consumer-1
test-group test-topic 11 - 0 - consumer-1-75e1a353-cd34-4e49-b88f-2e8da
[jira] [Comment Edited] (KAFKA-7026) Sticky assignor could assign a partition to multiple consumers (KIP-341)
[
https://issues.apache.org/jira/browse/KAFKA-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636871#comment-16636871
]
Narayan Periwal edited comment on KAFKA-7026 at 10/3/18 12:05 PM:
--
[~steven.aerts], can the issue of "consumer of the process not losing it's
subscription" come with RangeAssignor?
was (Author: nperiwal):
[~steven.aerts], can the issue of "consumer of the process not losing it's
subscription" come with RangeAssignor? The reason why I ask this is that
KAFKA-6717 raised by [~Yuancheng] is related to _StickyAssignor_
> Sticky assignor could assign a partition to multiple consumers (KIP-341)
>
>
> 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
> Labels: kip
> Fix For: 2.2.0
>
>
> 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)
[jira] [Comment Edited] (KAFKA-7026) Sticky assignor could assign a partition to multiple consumers (KIP-341)
[
https://issues.apache.org/jira/browse/KAFKA-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636871#comment-16636871
]
Narayan Periwal edited comment on KAFKA-7026 at 10/3/18 12:04 PM:
--
[~steven.aerts], can the issue of "consumer of the process not losing it's
subscription" come with RangeAssignor? The reason why I ask this is that
KAFKA-6717 raised by [~Yuancheng] is related to _StickyAssignor_
was (Author: nperiwal):
[~steven.aerts], can the issue of "consumer of the process not losing it's
subscription" come with RangeAssignor?
> Sticky assignor could assign a partition to multiple consumers (KIP-341)
>
>
> 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
> Labels: kip
> Fix For: 2.2.0
>
>
> 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)
