KAFKA-13967: Document guarantees for producer callbacks on transaction commit#12264
KAFKA-13967: Document guarantees for producer callbacks on transaction commit#12264hachikuji merged 1 commit intoapache:trunkfrom
Conversation
tombentley
left a comment
There was a problem hiding this comment.
Thanks @C0urante! @hachikuji does this look OK to you?
There was a problem hiding this comment.
| * 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.
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.
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.
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.
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.
Sounds good, done.
…-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)