-
Notifications
You must be signed in to change notification settings - Fork 15k
KAFKA-13967: Document guarantees for producer callbacks on transaction commit #12264
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
Conversation
tombentley
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @C0urante! @hachikuji does this look OK to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * If the transaction is committed successfully and this method returns without throwing an exception, it is guaranteed | |
| * that all {@link Callback callbacks} for records in the transaction will have been invoked and completed, either | |
| * successfully or by raising an exception. In the event that a callback fails (i.e., raises an exception), the producer | |
| * will still proceed with the transaction commit. | |
| * If the transaction is committed successfully and this method returns without throwing an exception, it is guaranteed | |
| * that all {@link Callback callbacks} for records in the transaction will have been invoked. Exceptions thrown by | |
| * callbacks are ignored; the producer proceeds to commit the transaction in any case. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, "invoked" means that the method has been called but not necessarily that it has completed (i.e., returned or thrown an exception), and given the multi-threaded nature of the producer, I'd like it if we could make that distinction so that there's no longer any room for doubt in users' minds on that front.
Fine with the new language in the last sentence though 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we allow a commit to proceed if any of the sends fail. The user has to abort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does a failing callback qualify as a failing send? Otherwise I'm not sure what part of this implies that a transaction will proceed if a send fails, and the previous paragraph explicitly calls that out already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think my confusion came from the phrase "either successfully or by raising an exception." I thought this was referring to the callback result (i.e. what we are passing to Callback.onCompletion). Perhaps we could just leave that part out since the next sentence is clarifying anyway?
If the transaction is committed successfully and this method returns without throwing an exception, it is guaranteed that all {@link Callback callbacks} for records in the transaction will have been invoked and completed. Note that exceptions thrown by callbacks are ignored; the producer proceeds to commit the transaction in any case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, done.
hachikuji
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM
…-2022 * apache/trunk: (52 commits) KAFKA-13967: Document guarantees for producer callbacks on transaction commit (apache#12264) [KAFKA-13848] Clients remain connected after SASL re-authentication f… (apache#12179) KAFKA-10000: Zombie fencing logic (apache#11779) KAFKA-13947: Use %d formatting for integers rather than %s (apache#12267) KAFKA-13929: Replace legacy File.createNewFile() with NIO.2 Files.createFile() (apache#12197) KAFKA-13780: Generate OpenAPI file for Connect REST API (apache#12067) KAFKA-13917: Avoid calling lookupCoordinator() in tight loop (apache#12180) KAFKA-10199: Implement removing active and standby tasks from the state updater (apache#12270) MINOR: Update Scala to 2.13.8 in gradle.properties (apache#12273) MINOR: add java 8/scala 2.12 deprecation info in doc (apache#12261) ... Conflicts: gradle.properties
Jira
Also added some
<p>tags to help organize the rendered Javadocs.Committer Checklist (excluded from commit message)