Pankraz76 opened a new pull request, #23993: URL: https://github.com/apache/kafka/pull/23993
…available leader Since KAFKA-20734, markers for a partition without an available leader (for example an offline partition) are kept in the unknown-broker queue of TransactionMarkerChannelManager until the partition has a leader again, instead of being dropped. The sender thread retries these markers from generateRequests() by calling addTxnMarkersToBrokerQueue(), which always ends with wakeup(). While the leader is still unavailable the marker is parked again, the wakeup makes the following poll return immediately, and the thread spins on getPartitionLeaderEndpoint() for as long as the partition stays offline. The wakeup is not needed on this path: generateRequests() runs on the sender thread, and markers moved to a broker queue are drained later in the same call. Re-enqueue parked markers without waking up the network client, and poll with a 100 ms bound while markers are parked, so they are retried after a backoff rather than in a tight loop or only when an unrelated event wakes up the thread. This follows the backoff used by NodeToControllerRequestThread for the same reason. Adding markers from other threads and from completion handlers still wakes up the sender. Tests: - TransactionMarkerChannelManagerTest: retrying a parked marker does not wake up the network client, and doWork() polls with the backoff while markers are parked and without a bound otherwise. - TransactionsTest (integration): commit while a partition hosted outside the transaction coordinator is offline, bring it back, and verify that a read_committed consumer sees the committed record. This covers the retry no longer relying on wakeup(). Claude-Session: https://claude.ai/code/session_01MTr23vJugZUPxMKex87743 Delete this text and replace it with a detailed description of your change. The PR title and body will become the squashed commit message. If you would like to tag individuals, add some commentary, upload images, or include other supplemental information that should not be part of the eventual commit message, please use a separate comment. If applicable, please include a summary of the testing strategy (including rationale) for the proposed change. Unit and/or integration tests are expected for any behavior change and system tests should be considered for larger changes. -- 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]
