kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From guozh...@apache.org
Subject kafka-site git commit: HOTFIX: MINOR: Remove duplicate list items.
Date Wed, 04 Jan 2017 02:06:45 GMT
Repository: kafka-site
Updated Branches:
  refs/heads/asf-site 8c86f8879 -> e853115d8


HOTFIX: MINOR: Remove duplicate list items.

This is a minor correction in site documentation that removes duplicate list items from the
following section https://kafka.apache.org/documentation/#design_compactionguarantees.

Author: Dhwani Katagade <dhwani_katagade@persistent.com>

Reviewers: Guozhang Wang <wangguoz@gmail.com>

Closes #38 from dhwanikatagade/HOTFIX_Documentation_remove_duplicate_list_item


Project: http://git-wip-us.apache.org/repos/asf/kafka-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/kafka-site/commit/e853115d
Tree: http://git-wip-us.apache.org/repos/asf/kafka-site/tree/e853115d
Diff: http://git-wip-us.apache.org/repos/asf/kafka-site/diff/e853115d

Branch: refs/heads/asf-site
Commit: e853115d80109e0e67d21a68c3ecfb058bbdb3bc
Parents: 8c86f88
Author: Dhwani Katagade <dhwani_katagade@persistent.com>
Authored: Tue Jan 3 18:06:41 2017 -0800
Committer: Guozhang Wang <wangguoz@gmail.com>
Committed: Tue Jan 3 18:06:41 2017 -0800

----------------------------------------------------------------------
 0100/design.html | 1 -
 0101/design.html | 3 ---
 081/design.html  | 1 -
 082/design.html  | 1 -
 090/design.html  | 1 -
 5 files changed, 7 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/kafka-site/blob/e853115d/0100/design.html
----------------------------------------------------------------------
diff --git a/0100/design.html b/0100/design.html
index 8d52359..fc32ea4 100644
--- a/0100/design.html
+++ b/0100/design.html
@@ -323,7 +323,6 @@ Log compaction guarantees the following:
 <li>Any consumer that stays caught-up to within the head of the log will see every
message that is written; these messages will have sequential offsets.
 <li>Ordering of messages is always maintained.  Compaction will never re-order messages,
just remove some.
 <li>The offset for a message never changes.  It is the permanent identifier for a position
in the log.
-<li>Any read progressing from offset 0 will see at least the final state of all records
in the order they were written. All delete markers for deleted records will be seen provided
the reader reaches the head of the log in a time period less than the topic's delete.retention.ms
setting (the default is 24 hours). This is important as delete marker removal happens concurrently
with read (and thus it is important that we not remove any delete marker prior to the reader
seeing it).
 <li>Any consumer progressing from the start of the log will see at least the <em>final</em>
state of all records in the order they were written.  All delete markers for deleted records
will be seen provided the consumer reaches the head of the log in a time period less than
the topic's <code>delete.retention.ms</code> setting (the default is 24 hours).
 This is important as delete marker removal happens concurrently with read, and thus it is
important that we do not remove any delete marker prior to the consumer seeing it.
 </ol>
 

http://git-wip-us.apache.org/repos/asf/kafka-site/blob/e853115d/0101/design.html
----------------------------------------------------------------------
diff --git a/0101/design.html b/0101/design.html
index 2548f93..222a587 100644
--- a/0101/design.html
+++ b/0101/design.html
@@ -489,9 +489,6 @@
     guarantee the minimum length of time must pass after a message is written before it could
be compacted. I.e. it provides a lower bound on how long each message will remain in the (uncompacted)
head.
     <li>Ordering of messages is always maintained.  Compaction will never re-order
messages, just remove some.
     <li>The offset for a message never changes.  It is the permanent identifier for
a position in the log.
-    <li>Any read progressing from offset 0 will see at least the final state of all
records in the order they were written. All delete markers for deleted records will be seen
provided the reader reaches the head of
-    the log in a time period less than the topic's delete.retention.ms setting (the default
is 24 hours). This is important as delete marker removal happens concurrently with read (and
thus it is important that we not
-    remove any delete marker prior to the reader seeing it).
     <li>Any consumer progressing from the start of the log will see at least the <em>final</em>
state of all records in the order they were written.  All delete markers for deleted records
will be seen provided the
     consumer reaches the head of the log in a time period less than the topic's <code>delete.retention.ms</code>
setting (the default is 24 hours).  This is important as delete marker removal happens concurrently
with
     read, and thus it is important that we do not remove any delete marker prior to the consumer
seeing it.

http://git-wip-us.apache.org/repos/asf/kafka-site/blob/e853115d/081/design.html
----------------------------------------------------------------------
diff --git a/081/design.html b/081/design.html
index 6c37f25..ccecdae 100644
--- a/081/design.html
+++ b/081/design.html
@@ -292,7 +292,6 @@ Log compaction guarantees the following:
 <li>Any consumer that stays caught-up to within the head of the log will see every
message that is written; these messages will have sequential offsets.
 <li>Ordering of messages is always maintained.  Compaction will never re-order messages,
just remove some.
 <li>The offset for a message never changes.  It is the permanent identifier for a position
in the log.
-<li>Any read progressing from offset 0 will see at least the final state of all records
in the order they were written. All delete markers for deleted records will be seen provided
the reader reaches the head of the log in a time period less than the topic's delete.retention.ms
setting (the default is 24 hours). This is important as delete marker removal happens concurrently
with read (and thus it is important that we not remove any delete marker prior to the reader
seeing it).
 <li>Any consumer progressing from the start of the log, will see at least the <em>final</em>
state of all records in the order they were written.  All delete markers for deleted records
will be seen provided the consumer reaches the head of the log in a time period less than
the topic's <code>delete.retention.ms</code> setting (the default is 24 hours).
 This is important as delete marker removal happens concurrently with read, and thus it is
important that we do not remove any delete marker prior to the consumer seeing it.
 </ol>
 

http://git-wip-us.apache.org/repos/asf/kafka-site/blob/e853115d/082/design.html
----------------------------------------------------------------------
diff --git a/082/design.html b/082/design.html
index 433d139..91bb4c1 100644
--- a/082/design.html
+++ b/082/design.html
@@ -306,7 +306,6 @@ Log compaction guarantees the following:
 <li>Any consumer that stays caught-up to within the head of the log will see every
message that is written; these messages will have sequential offsets.
 <li>Ordering of messages is always maintained.  Compaction will never re-order messages,
just remove some.
 <li>The offset for a message never changes.  It is the permanent identifier for a position
in the log.
-<li>Any read progressing from offset 0 will see at least the final state of all records
in the order they were written. All delete markers for deleted records will be seen provided
the reader reaches the head of the log in a time period less than the topic's delete.retention.ms
setting (the default is 24 hours). This is important as delete marker removal happens concurrently
with read (and thus it is important that we not remove any delete marker prior to the reader
seeing it).
 <li>Any consumer progressing from the start of the log, will see at least the <em>final</em>
state of all records in the order they were written.  All delete markers for deleted records
will be seen provided the consumer reaches the head of the log in a time period less than
the topic's <code>delete.retention.ms</code> setting (the default is 24 hours).
 This is important as delete marker removal happens concurrently with read, and thus it is
important that we do not remove any delete marker prior to the consumer seeing it.
 </ol>
 

http://git-wip-us.apache.org/repos/asf/kafka-site/blob/e853115d/090/design.html
----------------------------------------------------------------------
diff --git a/090/design.html b/090/design.html
index 439e087..08d82bc 100644
--- a/090/design.html
+++ b/090/design.html
@@ -323,7 +323,6 @@ Log compaction guarantees the following:
 <li>Any consumer that stays caught-up to within the head of the log will see every
message that is written; these messages will have sequential offsets.
 <li>Ordering of messages is always maintained.  Compaction will never re-order messages,
just remove some.
 <li>The offset for a message never changes.  It is the permanent identifier for a position
in the log.
-<li>Any read progressing from offset 0 will see at least the final state of all records
in the order they were written. All delete markers for deleted records will be seen provided
the reader reaches the head of the log in a time period less than the topic's delete.retention.ms
setting (the default is 24 hours). This is important as delete marker removal happens concurrently
with read (and thus it is important that we not remove any delete marker prior to the reader
seeing it).
 <li>Any consumer progressing from the start of the log, will see at least the <em>final</em>
state of all records in the order they were written.  All delete markers for deleted records
will be seen provided the consumer reaches the head of the log in a time period less than
the topic's <code>delete.retention.ms</code> setting (the default is 24 hours).
 This is important as delete marker removal happens concurrently with read, and thus it is
important that we do not remove any delete marker prior to the consumer seeing it.
 </ol>
 


Mime
View raw message