bookkeeper-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zhai...@apache.org
Subject [bookkeeper] branch master updated: ISSUE #485: Change 'segment' to 'fragment' in docs
Date Fri, 01 Sep 2017 00:13:10 GMT
This is an automated email from the ASF dual-hosted git repository.

zhaijia pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/bookkeeper.git


The following commit(s) were added to refs/heads/master by this push:
     new fd27e99  ISSUE #485: Change 'segment' to 'fragment' in docs
fd27e99 is described below

commit fd27e99ecbb152ef7bbf05a36a9d85c8997d3744
Author: Arvin <arvindevel@gmail.com>
AuthorDate: Fri Sep 1 08:12:57 2017 +0800

    ISSUE #485: Change 'segment' to 'fragment' in docs
    
    Descriptions of the changes in this PR:
     Change  'segment' to 'fragment' in docs, and make some relative code more clearer
    
    Author: Arvin <arvindevel@gmail.com>
    
    Reviewers: Jia Zhai <None>, Sijie Guo <sijie@apache.org>
    
    This closes #486 from ArvinDevel/issue_485, closes #485
---
 .../apache/bookkeeper/client/LedgerChecker.java    | 16 ++++++++--------
 .../bookkeeper/client/BookKeeperAdminTest.java     |  8 ++++----
 site/docs/4.5.0/admin/autorecovery.md              | 22 +++++++++++-----------
 site/docs/latest/admin/autorecovery.md             | 22 +++++++++++-----------
 4 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
index c9481bd..a90a366 100644
--- a/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
+++ b/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/LedgerChecker.java
@@ -200,16 +200,16 @@ public class LedgerChecker {
             curEnsemble = e.getValue();
         }
 
-        /* Checking the last segment of the ledger can be complicated in some cases.
+        /* Checking the last fragment of the ledger can be complicated in some cases.
          * In the case that the ledger is closed, we can just check the fragments of
-         * the segment as normal, except in the case that no entry was ever written,
+         * the ledger as normal, except in the case that no entry was ever written,
          * to the ledger, in which case we check no fragments.
          * In the case that the ledger is open, but enough entries have been written,
-         * for lastAddConfirmed to be set above the start entry of the segment, we
+         * for lastAddConfirmed to be set above the start entry of the fragment, we
          * can also check as normal.
          * However, if lastAddConfirmed cannot be trusted, such as when it's lower than
          * the first entry id, or not set at all, we cannot be sure if there has been
-         * data written to the segment. For this reason, we have to send a read request
+         * data written to the fragment. For this reason, we have to send a read request
          * to the bookies which should have the first entry. If they respond with
          * NoSuchEntry we can assume it was never written. If they respond with anything
          * else, we must assume the entry has been written, so we run the check.
@@ -221,9 +221,9 @@ public class LedgerChecker {
                 lastEntry = curEntryId;
             }
 
-            final Set<LedgerFragment> finalSegmentFragments = new HashSet<LedgerFragment>();
+            final Set<LedgerFragment> finalFragments = new HashSet<LedgerFragment>();
             for (int i = 0; i < curEnsemble.size(); i++) {
-                finalSegmentFragments.add(new LedgerFragment(lh, curEntryId,
+                finalFragments.add(new LedgerFragment(lh, curEntryId,
                         lastEntry, i));
             }
 
@@ -237,7 +237,7 @@ public class LedgerChecker {
                                               new GenericCallback<Boolean>() {
                                                   public void operationComplete(int rc, Boolean
result) {
                                                       if (result) {
-                                                          fragments.addAll(finalSegmentFragments);
+                                                          fragments.addAll(finalFragments);
                                                       }
                                                       checkFragments(fragments, cb);
                                                   }
@@ -250,7 +250,7 @@ public class LedgerChecker {
                 }
                 return;
             } else {
-                fragments.addAll(finalSegmentFragments);
+                fragments.addAll(finalFragments);
             }
         }
 
diff --git a/bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookKeeperAdminTest.java
b/bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookKeeperAdminTest.java
index 68956d8..e9cd823 100644
--- a/bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookKeeperAdminTest.java
+++ b/bookkeeper-server/src/test/java/org/apache/bookkeeper/client/BookKeeperAdminTest.java
@@ -193,7 +193,7 @@ public class BookKeeperAdminTest extends BookKeeperClusterTestCase {
 
         /*
          * since one of the bookie is killed, ensemble change happens when next
-         * write is made.So new segment will be created for those 2 ledgers.
+         * write is made.So new fragment will be created for those 2 ledgers.
          */
         for (int j = numOfEntries; j < 2 * numOfEntries; j++) {
             lh1.addEntry(j, "data".getBytes());
@@ -201,14 +201,14 @@ public class BookKeeperAdminTest extends BookKeeperClusterTestCase {
         }
         
         /*
-         * Here lh1 and lh2 have multiple segments and are writeclosed. But lh3 and lh4 are

-         * not writeclosed and contains only one segment.
+         * Here lh1 and lh2 have multiple fragments and are writeclosed. But lh3 and lh4
are
+         * not writeclosed and contains only one fragment.
          */
         lh1.close();
         lh2.close();
         
         /*
-         * If the last segment of the ledger is underreplicated and if the
+         * If the last fragment of the ledger is underreplicated and if the
          * ledger is not closed then it will remain underreplicated for
          * openLedgerRereplicationGracePeriod (by default 30 secs). For more
          * info. Check BOOKKEEPER-237 and BOOKKEEPER-325. But later
diff --git a/site/docs/4.5.0/admin/autorecovery.md b/site/docs/4.5.0/admin/autorecovery.md
index 64c6beb..bd11a88 100644
--- a/site/docs/4.5.0/admin/autorecovery.md
+++ b/site/docs/4.5.0/admin/autorecovery.md
@@ -37,7 +37,7 @@ $ bookkeeper-server/bin/bookkeeper org.apache.bookkeeper.tools.BookKeeperTools
\
 When you initiate a manual recovery process, the following happens:
 
 1. The client (the process running ) reads the metadata of active ledgers from ZooKeeper.
-1. The ledgers that contain segments from the failed bookie in their ensemble are selected.
+1. The ledgers that contain fragments from the failed bookie in their ensemble are selected.
 1. A recovery process is initiated for each ledger in this list and the rereplication process
is run for each ledger.
 1. Once all the ledgers are marked as fully replicated, bookie recovery is finished.
 
@@ -106,11 +106,11 @@ When the auditor sees that a bookie has disappeared, it immediately
scans the co
 
 Each replication worker watches for tasks being published by the auditor on the `/underreplicated/`
znode in ZooKeeper. When a new task appears, the replication worker will try to get a lock
on it. If it cannot acquire the lock, it will try the next entry. The locks are implemented
using ZooKeeper ephemeral znodes.
 
-The replication worker will scan through the rereplication task's ledger for segments of
which its local bookie is not a member. When it finds segments matching this criterion, it
will replicate the entries of that segment to the local bookie. If, after this process, the
ledger is fully replicated, the ledgers entry under /underreplicated/ is deleted, and the
lock is released. If there is a problem replicating, or there are still segments in the ledger
which are still underreplicated (du [...]
+The replication worker will scan through the rereplication task's ledger for fragments of
which its local bookie is not a member. When it finds fragments matching this criterion, it
will replicate the entries of that fragment to the local bookie. If, after this process, the
ledger is fully replicated, the ledgers entry under /underreplicated/ is deleted, and the
lock is released. If there is a problem replicating, or there are still fragments in the ledger
which are still underreplicated [...]
 
-If the replication worker finds a segment which needs rereplication, but does not have a
defined endpoint (i.e. the final segment of a ledger currently being written to), it will
wait for a grace period before attempting rereplication. If the segment needing rereplication
still does not have a defined endpoint, the ledger is fenced and rereplication then takes
place.
+If the replication worker finds a fragment which needs rereplication, but does not have a
defined endpoint (i.e. the final fragment of a ledger currently being written to), it will
wait for a grace period before attempting rereplication. If the fragment needing rereplication
still does not have a defined endpoint, the ledger is fenced and rereplication then takes
place.
 
-This avoids the situation in which a client is writing to a ledger and one of the bookies
goes down, but the client has not written an entry to that bookie before rereplication takes
place. The client could continue writing to the old segment, even though the ensemble for
the segment had changed. This could lead to data loss. Fencing prevents this scenario from
happening. In the normal case, the client will try to write to the failed bookie within the
grace period, and will have started  [...]
+This avoids the situation in which a client is writing to a ledger and one of the bookies
goes down, but the client has not written an entry to that bookie before rereplication takes
place. The client could continue writing to the old fragment, even though the ensemble for
the fragment had changed. This could lead to data loss. Fencing prevents this scenario from
happening. In the normal case, the client will try to write to the failed bookie within the
grace period, and will have starte [...]
 
 You can configure this grace period using the [`openLedgerRereplicationGracePeriod`](../../reference/config#openLedgerRereplicationGracePeriod)
parameter.
 
@@ -118,11 +118,11 @@ You can configure this grace period using the [`openLedgerRereplicationGracePeri
 
 The ledger rereplication process happens in these steps:
 
-1. The client goes through all ledger segments in the ledger, selecting those that contain
the failed bookie.
-1. A recovery process is initiated for each ledger segment in this list.
-   1. The client selects a bookie to which all entries in the ledger segment will be replicated;
In the case of autorecovery, this will always be the local bookie.
-   1. The client reads entries that belong to the ledger segment from other bookies in the
ensemble and writes them to the selected bookie.
-   1. Once all entries have been replicated, the zookeeper metadata for the segment is updated
to reflect the new ensemble.
-   1. The segment is marked as fully replicated in the recovery tool.
-1. Once all ledger segments are marked as fully replicated, the ledger is marked as fully
replicated.
+1. The client goes through all ledger fragments in the ledger, selecting those that contain
the failed bookie.
+1. A recovery process is initiated for each ledger fragment in this list.
+   1. The client selects a bookie to which all entries in the ledger fragment will be replicated;
In the case of autorecovery, this will always be the local bookie.
+   1. The client reads entries that belong to the ledger fragment from other bookies in the
ensemble and writes them to the selected bookie.
+   1. Once all entries have been replicated, the zookeeper metadata for the fragment is updated
to reflect the new ensemble.
+   1. The fragment is marked as fully replicated in the recovery tool.
+1. Once all ledger fragments are marked as fully replicated, the ledger is marked as fully
replicated.
   
diff --git a/site/docs/latest/admin/autorecovery.md b/site/docs/latest/admin/autorecovery.md
index d572346..b1dd078 100644
--- a/site/docs/latest/admin/autorecovery.md
+++ b/site/docs/latest/admin/autorecovery.md
@@ -37,7 +37,7 @@ $ bookkeeper-server/bin/bookkeeper shell recover \
 When you initiate a manual recovery process, the following happens:
 
 1. The client (the process running ) reads the metadata of active ledgers from ZooKeeper.
-1. The ledgers that contain segments from the failed bookie in their ensemble are selected.
+1. The ledgers that contain fragments from the failed bookie in their ensemble are selected.
 1. A recovery process is initiated for each ledger in this list and the rereplication process
is run for each ledger.
 1. Once all the ledgers are marked as fully replicated, bookie recovery is finished.
 
@@ -106,11 +106,11 @@ When the auditor sees that a bookie has disappeared, it immediately
scans the co
 
 Each replication worker watches for tasks being published by the auditor on the `/underreplicated/`
znode in ZooKeeper. When a new task appears, the replication worker will try to get a lock
on it. If it cannot acquire the lock, it will try the next entry. The locks are implemented
using ZooKeeper ephemeral znodes.
 
-The replication worker will scan through the rereplication task's ledger for segments of
which its local bookie is not a member. When it finds segments matching this criterion, it
will replicate the entries of that segment to the local bookie. If, after this process, the
ledger is fully replicated, the ledgers entry under /underreplicated/ is deleted, and the
lock is released. If there is a problem replicating, or there are still segments in the ledger
which are still underreplicated (du [...]
+The replication worker will scan through the rereplication task's ledger for fragments of
which its local bookie is not a member. When it finds fragments matching this criterion, it
will replicate the entries of that fragment to the local bookie. If, after this process, the
ledger is fully replicated, the ledgers entry under /underreplicated/ is deleted, and the
lock is released. If there is a problem replicating, or there are still fragments in the ledger
which are still underreplicated [...]
 
-If the replication worker finds a segment which needs rereplication, but does not have a
defined endpoint (i.e. the final segment of a ledger currently being written to), it will
wait for a grace period before attempting rereplication. If the segment needing rereplication
still does not have a defined endpoint, the ledger is fenced and rereplication then takes
place.
+If the replication worker finds a fragment which needs rereplication, but does not have a
defined endpoint (i.e. the final fragment of a ledger currently being written to), it will
wait for a grace period before attempting rereplication. If the fragment needing rereplication
still does not have a defined endpoint, the ledger is fenced and rereplication then takes
place.
 
-This avoids the situation in which a client is writing to a ledger and one of the bookies
goes down, but the client has not written an entry to that bookie before rereplication takes
place. The client could continue writing to the old segment, even though the ensemble for
the segment had changed. This could lead to data loss. Fencing prevents this scenario from
happening. In the normal case, the client will try to write to the failed bookie within the
grace period, and will have started  [...]
+This avoids the situation in which a client is writing to a ledger and one of the bookies
goes down, but the client has not written an entry to that bookie before rereplication takes
place. The client could continue writing to the old fragment, even though the ensemble for
the fragment had changed. This could lead to data loss. Fencing prevents this scenario from
happening. In the normal case, the client will try to write to the failed bookie within the
grace period, and will have starte [...]
 
 You can configure this grace period using the [`openLedgerRereplicationGracePeriod`](../../reference/config#openLedgerRereplicationGracePeriod)
parameter.
 
@@ -118,11 +118,11 @@ You can configure this grace period using the [`openLedgerRereplicationGracePeri
 
 The ledger rereplication process happens in these steps:
 
-1. The client goes through all ledger segments in the ledger, selecting those that contain
the failed bookie.
-1. A recovery process is initiated for each ledger segment in this list.
-   1. The client selects a bookie to which all entries in the ledger segment will be replicated;
In the case of autorecovery, this will always be the local bookie.
-   1. The client reads entries that belong to the ledger segment from other bookies in the
ensemble and writes them to the selected bookie.
-   1. Once all entries have been replicated, the zookeeper metadata for the segment is updated
to reflect the new ensemble.
-   1. The segment is marked as fully replicated in the recovery tool.
-1. Once all ledger segments are marked as fully replicated, the ledger is marked as fully
replicated.
+1. The client goes through all ledger fragments in the ledger, selecting those that contain
the failed bookie.
+1. A recovery process is initiated for each ledger fragment in this list.
+   1. The client selects a bookie to which all entries in the ledger fragment will be replicated;
In the case of autorecovery, this will always be the local bookie.
+   1. The client reads entries that belong to the ledger fragment from other bookies in the
ensemble and writes them to the selected bookie.
+   1. Once all entries have been replicated, the zookeeper metadata for the fragment is updated
to reflect the new ensemble.
+   1. The fragment is marked as fully replicated in the recovery tool.
+1. Once all ledger fragments are marked as fully replicated, the ledger is marked as fully
replicated.
   

-- 
To stop receiving notification emails like this one, please contact
['"commits@bookkeeper.apache.org" <commits@bookkeeper.apache.org>'].

Mime
View raw message