couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vatam...@apache.org
Subject [couchdb] branch 63012-scheduler updated: [fixup] README typos
Date Fri, 14 Apr 2017 20:28:40 GMT
This is an automated email from the ASF dual-hosted git repository.

vatamane pushed a commit to branch 63012-scheduler
in repository https://gitbox.apache.org/repos/asf/couchdb.git

The following commit(s) were added to refs/heads/63012-scheduler by this push:
       new  02c162e   [fixup] README typos
02c162e is described below

commit 02c162ec45a2c8bac85df23fb7413837b4a52e51
Author: Nick Vatamaniuc <vatamane@apache.org>
AuthorDate: Fri Apr 14 16:28:35 2017 -0400

    [fixup] README typos
---
 src/couch_replicator/README.md | 36 +++++++++++++++++-------------------
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/src/couch_replicator/README.md b/src/couch_replicator/README.md
index 1b0e01b..32a58be 100644
--- a/src/couch_replicator/README.md
+++ b/src/couch_replicator/README.md
@@ -8,10 +8,8 @@ everything is connected together.
 A natural place to start is the top applicatin supervisor:
 `couch_replicator_sup`. It's a `rest_for_one` so if a child process
 terminates, the rest of the childred in the hierarchy following it are also
-terminated. This structure implies a useful constraint -- children to the "right"
-if viewing it vertically with the root at the top, can safely call children
-on the "left", because this supervisor ensures those on the "left" will already
-be started and runnig.
+terminated. This structure implies a useful constraint -- children lower in
+the list can safely call their siblings which are higher in the list.
 
 A description of each child:
 
@@ -21,26 +19,26 @@ A description of each child:
     also used in replication tests to minotor for replication events.
     Notification is performed via the `couch_replicator_notifier:notify/1`
     function. It's the first (left-most) child because
-    `couch_replicator_clustering` is using.
+    `couch_replicator_clustering` uses it.
 
  * `couch_replicator_clustering`: This module maintains cluster membership
-    information for replication application and provides functions to check
+    information for the replication application and provides functions to check
     ownership of replication jobs. A cluster membership change is published via
-    the `gen_event` event server set up in the `couch_replication_event` child
-    above. Published events are `{cluster, stable}` when cluster membership has
-    stabilized, that it is not fluctuating anymore, and `{cluster, unstable}`
-    which indicates there was a recent change to the cluster membership and now
-    it's considered unstable. Listeners for cluster membership change include
-    `couch_replicator_doc_processor` and `couch_replicator_db_changes`. When
-    doc processor gets an `{cluster, stable}` event it will remove all the
-    replication jobs not belonging to the current node. When
-    `couch_replicator_db_chanages` gets a `{cluster, stable}` event, it will
-    restart `couch_multidb_changes` process it controls which will launch an
-    new scan of all the replicator databases.
+    the `gen_event` event server named `couch_replication_event` as previously
+    covered. Published events are `{cluster, stable}` when cluster membership
+    has stabilized, that it, no node membership changes in a given period, and
+    `{cluster, unstable}` which indicates there was a recent change to the
+    cluster membership and now it's considered unstable. Listeners for cluster
+    membership change include `couch_replicator_doc_processor` and
+    `couch_replicator_db_changes`. When doc processor gets an `{cluster,
+    stable}` event it will remove all the replication jobs not belonging to the
+    current node. When `couch_replicator_db_chanages` gets a `{cluster,
+    stable}` event, it will restart the `couch_multidb_changes` process it
+    controls, which will launch an new scan of all the replicator databases.
 
   * `couch_replicator_connection`: Maintains a global replication connection
-    pool. It allows reusing connection across replication tasks. Main interface
-    is a `acquire/1` and `release/1`. The main idea here is that once a
+    pool. It allows reusing connections across replication tasks. The Main
+    interface is `acquire/1` and `release/1`. The general idea is once a
     connection is established, it is kept around for
     `replicator.connection_close_interval` milliseconds in case another
     replication task wants to re-use it. It is worth pointing out how linking

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

Mime
View raw message