chickenchickenlove commented on code in PR #21469:
URL: https://github.com/apache/kafka/pull/21469#discussion_r2807129461
##########
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:
Thanks for your comments!!! 🙇‍♂️
Sorry to bother you!
I have two more questtions!
###1.
Sorry for my pool understanding...🙇‍♂️
I’m not fully sure which part of the TV2 code path would fail to proceed if
we don’t make changes here. Could you please share a bit more detail or point
me to where it gets blocked?
###2.
This change in the code/PR seems to introduce a new path where TV1 could
potentially reach an epoch value of 32767.
If TV1 has never experienced this issue in practice, would it make sense to
handle TV1 and TV2 differently—for example, similar to how
`prepareAbortOrCommit()` checks `supportEpochBump()`?
https://github.com/apache/kafka/blob/9e1f91d6264dfd6974485b967c3129539d1803dc/core/src/main/scala/kafka/coordinator/transaction/TransactionCoordinator.scala#L579
What do you think?
--
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]
