[ 
https://issues.apache.org/jira/browse/KAFKA-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111052#comment-18111052
 ] 

sanghyeok An commented on KAFKA-21021:
--------------------------------------

I think I should be able to submit the PR by the end of this weekend.
However, if you'd prefer to move things forward sooner while I'm still working 
on it, please feel free to take it over!

> test_fencing_static_consumer is flaky for consumer protocol when duplicate 
> static members do not start up at the same time
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-21021
>                 URL: https://issues.apache.org/jira/browse/KAFKA-21021
>             Project: Kafka
>          Issue Type: Bug
>          Components: system tests
>            Reporter: Sean Quah
>            Assignee: sanghyeok An
>            Priority: Minor
>
> test_fencing_static_consumer creates a group with 3 static members (consumer) 
> and tries to join 2 additional static members (conflict_consumer) using 
> duplicate instance ids (num_conflict_consumers=2). Under the consumer 
> protocol, the original 3 members are expected to remain active and keep their 
> assignments, while the 2 duplicate-instance-id members are rejected with a 
> fatal UnreleasedInstanceIdException and terminate.
> The test uses VerifiableConsumer to start the duplicate-instance-id members, 
> which considers them started when both nodes are simultaneously reporting a 
> non-Dead state. But since these consumers are destined to die within about a 
> second of starting, the "started" check only succeeds if both nodes happen to 
> be alive at the same polling instant. If one node's startup lags behind the 
> other's by more than ~1-second, the two nodes are never simultaneously 
> non-Dead, and VerifiableConsumer.start() times out after 120 seconds with 
> "Verifiable consumer didn't finish startup in 120 seconds," even though the 
> fencing itself behaved correctly.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to