AndrewJSchofield commented on code in PR #17454:
URL: https://github.com/apache/kafka/pull/17454#discussion_r1811146922

##########
docs/design.html:
##########
@@ -254,32 +254,32 @@ <h3 class="anchor-heading"><a id="semantics" 
class="anchor-link"></a><a href="#s
         <i>At least once</i>&mdash;Messages are never lost but may be 
redelivered.
     </li>
     <li>
-        <i>Exactly once</i>&mdash;this is what people actually want, each 
message is delivered once and only once.
+        <i>Exactly once</i>&mdash;Each message is delivered once and only once.
     </li>
     </ul>
 
     It's worth noting that this breaks down into two problems: the durability 
guarantees for publishing a message and the guarantees when consuming a message.
     <p>
-    Many systems claim to provide "exactly once" delivery semantics, but it is 
important to read the fine print, most of these claims are misleading (i.e. 
they don't translate to the case where consumers or producers
+    Many systems claim to provide "exactly-once" delivery semantics, but it is 
important to read the fine print, because sometimes these claims are misleading 
(i.e. they don't translate to the case where consumers or producers
     can fail, cases where there are multiple consumer processes, or cases 
where data written to disk can be lost).
     <p>
-    Kafka's semantics are straight-forward. When publishing a message we have 
a notion of the message being "committed" to the log. Once a published message 
is committed it will not be lost as long as one broker that
-    replicates the partition to which this message was written remains 
"alive". The definition of committed message, alive partition as well as a 
description of which types of failures we attempt to handle will be
+    Kafka's semantics are straightforward. When publishing a message we have a 
notion of the message being "committed" to the log. Once a published message is 
committed, it will not be lost as long as one broker that

Review Comment:
   This term "committed" is exactly the same as used in the reliability 
guarantees section of Kafka: The Definitive Guide. I'm not inclined to change 
it as a result.



-- 
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: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to