Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KAFKA-17898: Refine Epoch Bumping Logic #17849

Merged

Conversation

rreddy-22
Copy link
Contributor

@rreddy-22 rreddy-22 commented Nov 18, 2024

With KAFKA-14562, we implemented epoch bump on both the client and the server. Mentioned below are the different epoch bump scenarios we have on hand after enabled tv2

Non-Transactional Producers
• Epoch bumping is always allowed.
• Different code paths are used to handle epoch bumping.

Transactional Producers

  1. No Epoch Bump Allowed
    • coordinatorSupportsBumpingEpoch = false when initPIDVersion < 3 or initPIDVersion = null.

  2. Client-Triggered Epoch Bump Allowed
    • coordinatorSupportsBumpingEpoch = true when initPIDVersion >= 3.
    • TransactionVersion2Enabled = false when endTxnVersion < 5.

  3. Only Server-Triggered Epoch Bump Allowed
    • TransactionVersion2Enabled = true and endTxnVersion >= 5.

We want to refine the code and make it more structured to correctly handle epoch bumping in the above mentioned cases.

The changes made in this patch are:

  • Rename epochBumpRequired to epochBumpTriggerRequired to symbolize a manual epoch bump request from the client
  • Modify canEpochBump method according to the above mentioned scenarios

* making errors abortable without manual intervention.
*
* - **Non-Transactional Producers**:
* For non-transactional producers, errors are considered abortable since no transaction rollback is necessary.
Copy link
Member

@jolshan jolshan Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. This comment is a little confusing. I didn't think that idempotent producers had abortable errors. I think this method is only called from transactional apis.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oya that's an oversight on my part, since I added the condition !isTransactional and in these cases we set epochBumpRequired true and treat it as an abortable error I got confused

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove the !isTransactional condition too in this case?

@github-actions github-actions bot removed the small Small PRs label Nov 21, 2024
Copy link
Member

@jolshan jolshan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM if test look good. 👍

@jolshan jolshan merged commit 4fc9e44 into apache:trunk Nov 25, 2024
8 checks passed
chiacyu pushed a commit to chiacyu/kafka that referenced this pull request Nov 30, 2024
With KAFKA-14562, we implemented epoch bump on both the client and the server. Mentioned below are the different epoch bump scenarios we have on hand after enabled tv2

Non-Transactional Producers
• Epoch bumping is always allowed.
• Different code paths are used to handle epoch bumping.

Transactional Producers

No Epoch Bump Allowed
• coordinatorSupportsBumpingEpoch = false when initPIDVersion < 3 or initPIDVersion = null.

Client-Triggered Epoch Bump Allowed
• coordinatorSupportsBumpingEpoch = true when initPIDVersion >= 3.
• TransactionVersion2Enabled = false when endTxnVersion < 5.

Only Server-Triggered Epoch Bump Allowed
• TransactionVersion2Enabled = true and endTxnVersion >= 5.

We want to refine the code and make it more structured to correctly handle epoch bumping in the above mentioned cases.

The changes made in this patch are:

Rename epochBumpRequired to epochBumpTriggerRequired to symbolize a manual epoch bump request from the client
Modify canEpochBump method according to the above mentioned scenarios

Reviewers: Artem Livshits <[email protected]>, Calvin Liu <[email protected]>, Justine Olshan <[email protected]>
tedyu pushed a commit to tedyu/kafka that referenced this pull request Jan 6, 2025
With KAFKA-14562, we implemented epoch bump on both the client and the server. Mentioned below are the different epoch bump scenarios we have on hand after enabled tv2

Non-Transactional Producers
• Epoch bumping is always allowed.
• Different code paths are used to handle epoch bumping.

Transactional Producers

No Epoch Bump Allowed
• coordinatorSupportsBumpingEpoch = false when initPIDVersion < 3 or initPIDVersion = null.

Client-Triggered Epoch Bump Allowed
• coordinatorSupportsBumpingEpoch = true when initPIDVersion >= 3.
• TransactionVersion2Enabled = false when endTxnVersion < 5.

Only Server-Triggered Epoch Bump Allowed
• TransactionVersion2Enabled = true and endTxnVersion >= 5.

We want to refine the code and make it more structured to correctly handle epoch bumping in the above mentioned cases.

The changes made in this patch are:

Rename epochBumpRequired to epochBumpTriggerRequired to symbolize a manual epoch bump request from the client
Modify canEpochBump method according to the above mentioned scenarios

Reviewers: Artem Livshits <[email protected]>, Calvin Liu <[email protected]>, Justine Olshan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants