KAFKA-13412; Ensure initTransactions() safe for retry after timeout#11452
Merged
Conversation
dajac
reviewed
Nov 16, 2021
dajac
left a comment
Member
There was a problem hiding this comment.
@hachikuji Thanks the patch. I faced this issues a couple of times without really understanding the root cause. I am glad that you've fixed it! I left a few comments/questions.
| return result; | ||
| return result; | ||
| } else if (currentState == transientState) { | ||
| return result; |
Member
There was a problem hiding this comment.
Why don't we set pendingResult to null when isCompleted() is true here? I suppose that we assume that the currentState which transition to the next state whenever the response is received so we should never have a completed request here. Therefore, the "prior state" check will handle all the cases. Is my reasoning correct?
Contributor
Author
There was a problem hiding this comment.
The logic was pretty confusing, so I attempted to simplify it in the latest commit. The need to ensure that the result gets communicated to the user definitely makes this code more awkward.
hachikuji
commented
Nov 22, 2021
Contributor
Author
There was a problem hiding this comment.
The way we did this before was a little strange. Logically, it makes more sense for the partition to be added to the transaction before we append the record to the accumulator.
4fa74a9 to
4ba2fda
Compare
dajac
reviewed
Nov 23, 2021
dajac
left a comment
Member
There was a problem hiding this comment.
Thanks for the update. Overall, the changes look good to me. I left a few nits and some clarification questions.
hachikuji
added a commit
that referenced
this pull request
Jan 21, 2022
…11452) If the user's `initTransactions` call times out, the user is expected to retry. However, the producer will continue retrying the `InitProducerId` request in the background. If it happens to return before the user retry of `initTransactions`, then the producer will raise an exception about an invalid state transition. The patch fixes the issue by tracking the pending state transition until the user has acknowledged the operation's result. In the case of `initTransactions`, even if the `InitProducerId` returns in the background and the state changes, we can still retry the `initTransactions` call to obtain the result. Reviewers: David Jacot <djacot@confluent.io>
3 tasks
hachikuji
added a commit
that referenced
this pull request
Apr 5, 2022
…l batch (#11995) Fixes a regression introduced in #11452. Following [KIP-480](https://cwiki.apache.org/confluence/display/KAFKA/KIP-480%3A+Sticky+Partitioner), the `Partitioner` will receive a callback when a batch has been completed so that it can choose another partition. Because of this, we have to wait until the batch has been successfully appended to the accumulator before adding the partition in `TransactionManager.maybeAddPartition`. This is still safe because the `Sender` cannot dequeue a batch from the accumulator until it has been added to the transaction successfully. Reviewers: Artem Livshits <84364232+artemlivshits@users.noreply.github.com>, David Jacot <djacot@confluent.io>, Tom Bentley <tbentley@redhat.com>
hachikuji
added a commit
that referenced
this pull request
Apr 5, 2022
…l batch (#11995) Fixes a regression introduced in #11452. Following [KIP-480](https://cwiki.apache.org/confluence/display/KAFKA/KIP-480%3A+Sticky+Partitioner), the `Partitioner` will receive a callback when a batch has been completed so that it can choose another partition. Because of this, we have to wait until the batch has been successfully appended to the accumulator before adding the partition in `TransactionManager.maybeAddPartition`. This is still safe because the `Sender` cannot dequeue a batch from the accumulator until it has been added to the transaction successfully. Reviewers: Artem Livshits <84364232+artemlivshits@users.noreply.github.com>, David Jacot <djacot@confluent.io>, Tom Bentley <tbentley@redhat.com>
hachikuji
added a commit
that referenced
this pull request
Apr 5, 2022
…l batch (#11995) Fixes a regression introduced in #11452. Following [KIP-480](https://cwiki.apache.org/confluence/display/KAFKA/KIP-480%3A+Sticky+Partitioner), the `Partitioner` will receive a callback when a batch has been completed so that it can choose another partition. Because of this, we have to wait until the batch has been successfully appended to the accumulator before adding the partition in `TransactionManager.maybeAddPartition`. This is still safe because the `Sender` cannot dequeue a batch from the accumulator until it has been added to the transaction successfully. Reviewers: Artem Livshits <84364232+artemlivshits@users.noreply.github.com>, David Jacot <djacot@confluent.io>, Tom Bentley <tbentley@redhat.com>
jeffkbkim
pushed a commit
to confluentinc/kafka
that referenced
this pull request
May 12, 2022
…pache#11452) If the user's `initTransactions` call times out, the user is expected to retry. However, the producer will continue retrying the `InitProducerId` request in the background. If it happens to return before the user retry of `initTransactions`, then the producer will raise an exception about an invalid state transition. The patch fixes the issue by tracking the pending state transition until the user has acknowledged the operation's result. In the case of `initTransactions`, even if the `InitProducerId` returns in the background and the state changes, we can still retry the `initTransactions` call to obtain the result. Reviewers: David Jacot <djacot@confluent.io>
jeffkbkim
pushed a commit
to confluentinc/kafka
that referenced
this pull request
May 12, 2022
…l batch (apache#11995) Fixes a regression introduced in apache#11452. Following [KIP-480](https://cwiki.apache.org/confluence/display/KAFKA/KIP-480%3A+Sticky+Partitioner), the `Partitioner` will receive a callback when a batch has been completed so that it can choose another partition. Because of this, we have to wait until the batch has been successfully appended to the accumulator before adding the partition in `TransactionManager.maybeAddPartition`. This is still safe because the `Sender` cannot dequeue a batch from the accumulator until it has been added to the transaction successfully. Reviewers: Artem Livshits <84364232+artemlivshits@users.noreply.github.com>, David Jacot <djacot@confluent.io>, Tom Bentley <tbentley@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If the user's
initTransactionscall times out, the user is expected to retry. However, the producer will continue retrying theInitProducerIdrequest in the background. If it happens to return before the user retry ofinitTransactions, then the producer will raise an exception about an invalid state transition.The patch fixes the issue by checking both the current state as well as the prior state in order to validate whether the retry is expected.
Committer Checklist (excluded from commit message)