lucasbru opened a new pull request, #22450:
URL: https://github.com/apache/kafka/pull/22450

   When a Kafka Streams application requests a shutdown of the whole 
application, or when an active task is found to be corrupted under 
exactly-once, `StreamThread` enforces a consumer rebalance. In the classic 
protocol both of these need a rebalance because the work is propagated to the 
rest of the group through the client-side assignor: a shutdown request is 
encoded into the assignment so every member learns it should stop, and a 
corrupted-task recovery (KAFKA-12486) lets the high-availability assignor 
temporarily move the task to a standby while the affected client restores its 
state from scratch.
   
   Under the Streams group protocol (KIP-1071) rebalances are driven by the 
broker, so neither of these relies on a client-enforced rebalance anymore. The 
shutdown request is propagated through the Streams group heartbeat, and 
corrupted-task recovery is entirely local: the task is closed dirty, revived, 
and re-initialized with its input offsets reset, after which any 
high-availability failover is the broker's responsibility. In both cases the 
call to `Consumer.enforceRebalance` does nothing except make the 
`AsyncKafkaConsumer` log "Operation not supported in new consumer group 
protocol". During shutdown this is logged on every run-loop iteration, which is 
what surfaced the issue.
   
   This change skips the `enforceRebalance` calls when the thread is running 
under the Streams group protocol, leaving the classic-protocol behavior 
untouched. The third `enforceRebalance` call site, the probing/followup 
rebalance, is intentionally left alone because it is only reachable when the 
client-side `StreamsPartitionAssignor` schedules a followup rebalance, which 
never happens under the Streams group protocol.
   
   Added unit tests covering both guarded call sites under the Streams group 
protocol, and verified the existing classic-protocol behavior is unchanged.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to