artemlivshits commented on code in PR #21469:
URL: https://github.com/apache/kafka/pull/21469#discussion_r2820749773
##########
transaction-coordinator/src/main/java/org/apache/kafka/coordinator/transaction/TransactionMetadata.java:
##########
@@ -139,11 +139,12 @@ public TxnTransitMetadata prepareNoTransit() {
public TxnTransitMetadata prepareFenceProducerEpoch() {
if (producerEpoch == Short.MAX_VALUE)
- throw new IllegalStateException("Cannot fence producer with epoch
equal to Short.MaxValue since this would overflow");
+ LOGGER.error("Fencing producer {} {} with epoch equal to
Short.MaxValue, this must not happen unless there is a bug", transactionalId,
producerId);
// If we've already failed to fence an epoch (because the write to the
log failed), we don't increase it again.
// This is safe because we never return the epoch to client if we fail
to fence the epoch
- short bumpedEpoch = hasFailedEpochFence ? producerEpoch : (short)
(producerEpoch + 1);
+ // Also don't increase if producerEpoch is already at max, to avoid
overflow.
+ short bumpedEpoch = hasFailedEpochFence || producerEpoch ==
Short.MAX_VALUE ? producerEpoch : (short) (producerEpoch + 1);
Review Comment:
For the question 1 there are a couple points:
1a. For TV2 when a transaction is aborted on timeout or on InitiProducerId
it would first call `prepareFenceProducerEpoch`. If an exception is thrown
here, the function wouldn't pass further.
2a. The goal of this change is not to fix a specific bug that could lead to
max value epoch, specific bugs should get fixed correspondingly. The goal of
this change is to provide a path to recovery from the state that is made by a
bug. So even though there are no known bugs with TV1 that could result in this
state, the "way out" should be present.
For the question 2 -- the path was already present for TV1 I believe, when
fencing happens the epoch is first bumped and can be max value. The logic is
already handled differently (TV1 handling even has its own function).
--
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]
