This is an automated email from the ASF dual-hosted git repository.
kturner pushed a commit to branch gh-pages
in repository https://gitbox.apache.org/repos/asf/fluo-website.git
The following commit(s) were added to refs/heads/gh-pages by this push:
new a4862db Fix some typos (#125)
a4862db is described below
commit a4862dbd565d06984d558fffda1701f0065835ce
Author: Lucas Lima Vieira <lima.luca...@gmail.com>
AuthorDate: Tue Feb 20 14:49:42 2018 -0300
Fix some typos (#125)
---
README.md | 2 +-
_posts/blog/2016-05-17-webindex-long-run-2.md | 2 +-
_posts/release/2014-10-02-fluo-1.0.0-alpha-1.md | 2 +-
_recipes-1-2/recipes/combine-queue.md | 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/README.md b/README.md
index 6f4de1b..7ac54ee 100644
--- a/README.md
+++ b/README.md
@@ -28,7 +28,7 @@ a Fluo Recipes release, replace any reference to `fluo` with
`recipes`.
## Create documentation for next release
-Below are steps to create documentaton for the next release of Fluo or Fluo
Recipes. The
+Below are steps to create documentation for the next release of Fluo or Fluo
Recipes. The
directions below are for creating Fluo 1.3 docs from 1.2 docs. For Fluo
Recipes documentation,
replace any reference to `fluo` with `recipes`.
diff --git a/_posts/blog/2016-05-17-webindex-long-run-2.md
b/_posts/blog/2016-05-17-webindex-long-run-2.md
index fdfece7..cbb10eb 100644
--- a/_posts/blog/2016-05-17-webindex-long-run-2.md
+++ b/_posts/blog/2016-05-17-webindex-long-run-2.md
@@ -46,7 +46,7 @@ that does not last.
CPU Utilization
---------------
-Inorder to get higher throughput changes were made to reduce CPU usage and
+In order to get higher throughput changes were made to reduce CPU usage and
evenly spread CPU usage across the cluster. The following plot shows the CPU
usage of all nodes across the cluster during the test. Unfortunately this data
was not kept for the previous run. One issue that caused problems in the
diff --git a/_posts/release/2014-10-02-fluo-1.0.0-alpha-1.md
b/_posts/release/2014-10-02-fluo-1.0.0-alpha-1.md
index 79689ad..cbb2daf 100644
--- a/_posts/release/2014-10-02-fluo-1.0.0-alpha-1.md
+++ b/_posts/release/2014-10-02-fluo-1.0.0-alpha-1.md
@@ -30,7 +30,7 @@ MiniAccumulo and MiniFluo make it easy to start a local Fluo
instance for integr
#### Garbage Collection
-Without garbage collection, the columnns in a Fluo table would grow without
bound as updates are applied over time. Because of this, it's important to
clean up old fully-processed (and no longer being read) transaction data. The
initial implementation of garbage collection kept N versions of columns.
[Fluo-8][8] added the ability to garbage collect all column versions that are
no longer being read by transactions anywhere else in the cluster.
+Without garbage collection, the columns in a Fluo table would grow without
bound as updates are applied over time. Because of this, it's important to
clean up old fully-processed (and no longer being read) transaction data. The
initial implementation of garbage collection kept N versions of columns.
[Fluo-8][8] added the ability to garbage collect all column versions that are
no longer being read by transactions anywhere else in the cluster.
#### MapReduce InputFormat
diff --git a/_recipes-1-2/recipes/combine-queue.md
b/_recipes-1-2/recipes/combine-queue.md
index 56cf51c..628f528 100644
--- a/_recipes-1-2/recipes/combine-queue.md
+++ b/_recipes-1-2/recipes/combine-queue.md
@@ -10,7 +10,7 @@ When many transactions try to modify the same keys,
collisions will occur. Too
cause transactions to fail and throughput to nose dive. For example, consider
[phrasecount]
which has many transactions processing documents. Each transaction counts the
phrases in a document
and then updates global phrase counts. Since transaction attempts to update
many phrases
-, the probability of collisions is high.
+, the probbaility of collisions is high.
## Solution
@@ -195,7 +195,7 @@ This recipe makes two important guarantees about updates
for a key when it
calls `process()` on a [ChangeObserver].
* The new value reported for an update will be derived from combining all
- updates that were committed before the transaction thats processing updates
+ updates that were committed before the transaction that's processing updates
started. The implementation may have to make multiple passes over queued
updates to achieve this. In the situation where TX1 queues a `+1` and later
TX2 queues a `-1` for the same key, there is no need to worry about only
seeing
--
To stop receiving notification emails like this one, please contact
ktur...@apache.org.
