This is an automated email from the ASF dual-hosted git repository.
cjmctague pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/fluo-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 544bde8 Jekyll build from gh-pages:ccdd402
544bde8 is described below
commit 544bde85495fe15b88e8934d8011860e48af91a9
Author: Christopher McTague <[email protected]>
AuthorDate: Wed Aug 29 10:32:05 2018 -0400
Jekyll build from gh-pages:ccdd402
Spelling corrections for the website (#164)
---
README.md | 2 +-
api/index.html | 2 +-
docs/fluo-recipes/1.0.0-beta-1/cfm/index.html | 4 ++--
docs/fluo-recipes/1.0.0-beta-1/export-queue/index.html | 8 ++++----
docs/fluo-recipes/1.0.0-beta-1/table-optimization/index.html | 2 +-
docs/fluo-recipes/1.0.0-beta-1/transient/index.html | 8 ++++----
docs/fluo-recipes/1.0.0-beta-2/cfm/index.html | 4 ++--
docs/fluo-recipes/1.0.0-beta-2/export-queue/index.html | 8 ++++----
docs/fluo-recipes/1.0.0-beta-2/index.html | 6 +++---
docs/fluo-recipes/1.0.0-beta-2/table-optimization/index.html | 2 +-
docs/fluo-recipes/1.0.0-beta-2/testing/index.html | 2 +-
docs/fluo-recipes/1.0.0-beta-2/transient/index.html | 8 ++++----
docs/fluo-recipes/1.0.0-incubating/cfm/index.html | 4 ++--
docs/fluo-recipes/1.0.0-incubating/export-queue/index.html | 8 ++++----
docs/fluo-recipes/1.0.0-incubating/table-optimization/index.html | 6 +++---
docs/fluo-recipes/1.0.0-incubating/testing/index.html | 2 +-
docs/fluo-recipes/1.0.0-incubating/transient/index.html | 6 +++---
docs/fluo-recipes/1.1.0-incubating/combine-queue/index.html | 2 +-
docs/fluo-recipes/1.1.0-incubating/export-queue/index.html | 8 ++++----
docs/fluo-recipes/1.1.0-incubating/table-optimization/index.html | 6 +++---
docs/fluo-recipes/1.1.0-incubating/testing/index.html | 2 +-
docs/fluo-recipes/1.1.0-incubating/transient/index.html | 6 +++---
docs/fluo-recipes/1.2/recipes/combine-queue.html | 2 +-
docs/fluo/1.0.0-beta-1/index.html | 2 +-
docs/fluo/1.0.0-beta-1/metrics/index.html | 4 ++--
feed.xml | 6 +++---
release/fluo-1.0.0-alpha-1/index.html | 2 +-
release/fluo-1.2.0/index.html | 2 +-
search_data.json | 6 +++---
29 files changed, 65 insertions(+), 65 deletions(-)
diff --git a/README.md b/README.md
index 7ac54ee..7f967f6 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
# Apache Fluo website
Code powering the Apache Fluo website
([https://fluo.apache.org](https://fluo.apache.org)).
-[Contributing](CONTRIBUTING.md) decribes how to test locally.
+[Contributing](CONTRIBUTING.md) describes how to test locally.
## Update website for new release
diff --git a/api/index.html b/api/index.html
index 7998112..91ccd5c 100644
--- a/api/index.html
+++ b/api/index.html
@@ -121,7 +121,7 @@
<h4 id="apache-fluo-api">Apache Fluo API</h4>
<ul>
- <li><a href="https://javadoc.io/doc/org.apache.fluo/fluo-api/1.2.0/";
target="_blank">1.2.0</a> - Februrary 26, 2018</li>
+ <li><a href="https://javadoc.io/doc/org.apache.fluo/fluo-api/1.2.0/";
target="_blank">1.2.0</a> - February 26, 2018</li>
<li><a
href="https://javadoc.io/doc/org.apache.fluo/fluo-api/1.1.0-incubating/";
target="_blank">1.1.0-incubating</a> - June 12, 2017</li>
<li><a
href="https://javadoc.io/doc/org.apache.fluo/fluo-api/1.0.0-incubating/";
target="_blank">1.0.0-incubating</a> - October 14, 2016</li>
</ul>
diff --git a/docs/fluo-recipes/1.0.0-beta-1/cfm/index.html
b/docs/fluo-recipes/1.0.0-beta-1/cfm/index.html
index 65802e5..74a6d44 100644
--- a/docs/fluo-recipes/1.0.0-beta-1/cfm/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-1/cfm/index.html
@@ -305,7 +305,7 @@ old value if needed.</p>
<span class="o">}</span>
<span class="k">if</span> <span class="o">(</span><span
class="n">sum</span> <span class="o">==</span> <span class="mi">0</span><span
class="o">)</span> <span class="o">{</span>
- <span class="c1">//returning absent will cause the collision free map
to delte the current key</span>
+ <span class="c1">//returning absent will cause the collision free map
to delete the current key</span>
<span class="k">return</span> <span class="n">Optional</span><span
class="o">.</span><span class="na">absent</span><span class="o">();</span>
<span class="o">}</span> <span class="k">else</span> <span
class="o">{</span>
<span class="k">return</span> <span class="n">Optional</span><span
class="o">.</span><span class="na">of</span><span class="o">(</span><span
class="n">sum</span><span class="o">);</span>
@@ -346,7 +346,7 @@ calls <code
class="highlighter-rouge">updatingValues()</code> on an <code class=
<ul>
<li>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 <code
class="highlighter-rouge">+1</code> and later
TX2 queues a <code class="highlighter-rouge">-1</code> for the same key, there
is no need to worry about only seeing
diff --git a/docs/fluo-recipes/1.0.0-beta-1/export-queue/index.html
b/docs/fluo-recipes/1.0.0-beta-1/export-queue/index.html
index 5af0576..dd1dae6 100644
--- a/docs/fluo-recipes/1.0.0-beta-1/export-queue/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-1/export-queue/index.html
@@ -151,7 +151,7 @@ transaction.</p>
<span class="kd">private</span> <span class="kd">static</span> <span
class="kd">final</span> <span class="n">TYPEL</span> <span class="o">=</span>
<span class="k">new</span> <span class="n">TypeLayer</span><span
class="o">(</span><span class="k">new</span> <span
class="n">StringEncoder</span><span class="o">());</span>
- <span class="c1">//reperesents a Query system extrnal to Fluo that is
updated by Fluo</span>
+ <span class="c1">//represents a Query system external to Fluo that is
updated by Fluo</span>
<span class="n">QuerySystem</span> <span class="n">querySystem</span><span
class="o">;</span>
<span class="nd">@Override</span>
@@ -276,7 +276,7 @@ application.</p>
<span class="c1">//initialize Fluo using fluoConfig</span>
</code></pre></div></div>
-<p>Below is updated version of the observer from above thats now using the
export
+<p>Below is updated version of the observer from above that’s now using the
export
queue.</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="kd">public</span> <span
class="kd">class</span> <span class="nc">MyObserver</span> <span
class="kd">extends</span> <span class="n">AbstractObserver</span> <span
class="o">{</span>
@@ -375,7 +375,7 @@ that creates the export value.</p>
<p>In the example above only one transaction will succeed because both are
setting
<code class="highlighter-rouge">row1 fam1:qual1</code>. Since adding to the
export queue is part of the
transaction, only the transaction that succeeds will add something to the
-queue. If the funtion ek() in the example is deterministic, then both
+queue. If the function ek() in the example is deterministic, then both
transactions would have been trying to add the same key to the export
queue.</p>
<p>With the above method, we know that transactions adding entries to the
queue for
@@ -389,7 +389,7 @@ same key. Both transactions succeed because they are
writing to different
cells (<code class="highlighter-rouge">rowB fam1:qual2</code> and <code
class="highlighter-rouge">rowA fam1:qual2</code>). This approach makes it more
difficult to reason about export entries with the same key, because the
transactions adding those entries could have overlapped in time. This is an
-example of write skew mentioned in the Percolater paper.</p>
+example of write skew mentioned in the Percolator paper.</p>
<ol>
<li>TH1 : key1 = ek(<code class="highlighter-rouge">row1</code>,<code
class="highlighter-rouge">fam1:qual1</code>)</li>
diff --git a/docs/fluo-recipes/1.0.0-beta-1/table-optimization/index.html
b/docs/fluo-recipes/1.0.0-beta-1/table-optimization/index.html
index 9e47324..34d7a45 100644
--- a/docs/fluo-recipes/1.0.0-beta-1/table-optimization/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-1/table-optimization/index.html
@@ -162,7 +162,7 @@ selective optimizations is need look into using the
following methods instead.</
<h2 id="command-example">Command Example</h2>
<p>Fluo Recipes provides an easy way to optimize a Fluo table for configured
-recipes from the command line. This should be done after configuring reciped
+recipes from the command line. This should be done after configuring recipes
and initializing Fluo. Below are example command for initializing in this
way.</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>
diff --git a/docs/fluo-recipes/1.0.0-beta-1/transient/index.html
b/docs/fluo-recipes/1.0.0-beta-1/transient/index.html
index 2701ab1..f61195d 100644
--- a/docs/fluo-recipes/1.0.0-beta-1/transient/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-1/transient/index.html
@@ -127,7 +127,7 @@
<h2 id="background">Background</h2>
<p>Some recipes store transient data in a portion of the Fluo table. Transient
-data is data thats continually being added and deleted. Also these transient
+data is data that’s continually being added and deleted. Also these transient
data ranges contain no long term data. The way Fluo works, when data is
deleted a delete marker is inserted but the data is actually still there. Over
time these transient ranges of the table will have a lot more delete markers
@@ -135,7 +135,7 @@ than actual data if nothing is done. If nothing is done,
then processing
transient data will get increasingly slower over time.</p>
<p>These deleted markers can be cleaned up by forcing Accumulo to compact the
-Fluo table, which will run Fluos garbage collection iterator. However,
+Fluo table, which will run Fluo’s garbage collection iterator. However,
compacting the entire table to clean up these ranges within a table is
overkill. Alternatively, Accumulo supports compacting ranges of a table. So
a good solution to the delete marker problem is to periodically compact just
@@ -156,7 +156,7 @@ using this.</p>
<span class="n">transientRegistry</span><span class="o">.</span><span
class="na">addTransientRange</span><span class="o">(</span><span
class="k">new</span> <span class="n">RowRange</span><span
class="o">(</span><span class="n">startRow</span><span class="o">,</span> <span
class="n">endRow</span><span class="o">));</span>
<span class="c1">//Initialize Fluo using fluoConfig. This will store the
registered ranges in</span>
-<span class="c1">//zookeeper making them availiable on any node later.</span>
+<span class="c1">//zookeeper making them available on any node later.</span>
</code></pre></div></div>
<h2 id="compacting-transient-ranges">Compacting Transient Ranges</h2>
@@ -177,7 +177,7 @@ command line using the <code class="highlighter-rouge">fluo
exec</code> command
</code></pre></div></div>
<p>If no arguments are specified the command will call <code
class="highlighter-rouge">compactTransient()</code> once.
-If only <code class="highlighter-rouge"><interval></code> is specied the
command will loop forever calling
+If only <code class="highlighter-rouge"><interval></code> is specified,
the command will loop forever calling
<code class="highlighter-rouge">compactTransient()</code> sleeping <code
class="highlighter-rouge"><interval></code> seconds between calls. If
<code class="highlighter-rouge"><count></code>
is additionally specified then the command will only loop <code
class="highlighter-rouge"><count></code> times.</p>
diff --git a/docs/fluo-recipes/1.0.0-beta-2/cfm/index.html
b/docs/fluo-recipes/1.0.0-beta-2/cfm/index.html
index efbe341..4f4ae67 100644
--- a/docs/fluo-recipes/1.0.0-beta-2/cfm/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-2/cfm/index.html
@@ -305,7 +305,7 @@ old value if needed.</p>
<span class="o">}</span>
<span class="k">if</span> <span class="o">(</span><span
class="n">sum</span> <span class="o">==</span> <span class="mi">0</span><span
class="o">)</span> <span class="o">{</span>
- <span class="c1">//returning absent will cause the collision free map
to delte the current key</span>
+ <span class="c1">//returning absent will cause the collision free map
to delete the current key</span>
<span class="k">return</span> <span class="n">Optional</span><span
class="o">.</span><span class="na">absent</span><span class="o">();</span>
<span class="o">}</span> <span class="k">else</span> <span
class="o">{</span>
<span class="k">return</span> <span class="n">Optional</span><span
class="o">.</span><span class="na">of</span><span class="o">(</span><span
class="n">sum</span><span class="o">);</span>
@@ -346,7 +346,7 @@ calls <code
class="highlighter-rouge">updatingValues()</code> on an <code class=
<ul>
<li>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 <code
class="highlighter-rouge">+1</code> and later
TX2 queues a <code class="highlighter-rouge">-1</code> for the same key, there
is no need to worry about only seeing
diff --git a/docs/fluo-recipes/1.0.0-beta-2/export-queue/index.html
b/docs/fluo-recipes/1.0.0-beta-2/export-queue/index.html
index edc7886..8999f52 100644
--- a/docs/fluo-recipes/1.0.0-beta-2/export-queue/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-2/export-queue/index.html
@@ -152,7 +152,7 @@ transaction.</p>
<span class="kd">private</span> <span class="kd">static</span> <span
class="kd">final</span> <span class="n">TYPEL</span> <span class="o">=</span>
<span class="k">new</span> <span class="n">TypeLayer</span><span
class="o">(</span><span class="k">new</span> <span
class="n">StringEncoder</span><span class="o">());</span>
- <span class="c1">//reperesents a Query system extrnal to Fluo that is
updated by Fluo</span>
+ <span class="c1">//represents a Query system external to Fluo that is
updated by Fluo</span>
<span class="n">QuerySystem</span> <span class="n">querySystem</span><span
class="o">;</span>
<span class="nd">@Override</span>
@@ -277,7 +277,7 @@ application.</p>
<span class="c1">//initialize Fluo using fluoConfig</span>
</code></pre></div></div>
-<p>Below is updated version of the observer from above thats now using the
export
+<p>Below is updated version of the observer from above that’s now using the
export
queue.</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="kd">public</span> <span
class="kd">class</span> <span class="nc">MyObserver</span> <span
class="kd">extends</span> <span class="n">AbstractObserver</span> <span
class="o">{</span>
@@ -376,7 +376,7 @@ that creates the export value.</p>
<p>In the example above only one transaction will succeed because both are
setting
<code class="highlighter-rouge">row1 fam1:qual1</code>. Since adding to the
export queue is part of the
transaction, only the transaction that succeeds will add something to the
-queue. If the funtion ek() in the example is deterministic, then both
+queue. If the function ek() in the example is deterministic, then both
transactions would have been trying to add the same key to the export
queue.</p>
<p>With the above method, we know that transactions adding entries to the
queue for
@@ -390,7 +390,7 @@ same key. Both transactions succeed because they are
writing to different
cells (<code class="highlighter-rouge">rowB fam1:qual2</code> and <code
class="highlighter-rouge">rowA fam1:qual2</code>). This approach makes it more
difficult to reason about export entries with the same key, because the
transactions adding those entries could have overlapped in time. This is an
-example of write skew mentioned in the Percolater paper.</p>
+example of write skew mentioned in the Percolator paper.</p>
<ol>
<li>TH1 : key1 = ek(<code class="highlighter-rouge">row1</code>,<code
class="highlighter-rouge">fam1:qual1</code>)</li>
diff --git a/docs/fluo-recipes/1.0.0-beta-2/index.html
b/docs/fluo-recipes/1.0.0-beta-2/index.html
index c2f37f8..53ba82b 100644
--- a/docs/fluo-recipes/1.0.0-beta-2/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-2/index.html
@@ -175,19 +175,19 @@ dependency on Spark.</p>
<span class="nt"><artifactId></span>fluo-recipes-kryo<span
class="nt"></artifactId></span>
<span class="nt"><version></span>${fluo-recipes.version}<span
class="nt"></version></span>
<span class="nt"></dependency></span>
- <span class="c"><!--optional dependency assist w/ intergrating Accumulo
and Fluo --></span>
+ <span class="c"><!--optional dependency assist w/ integrating Accumulo
and Fluo --></span>
<span class="nt"><dependency></span>
<span class="nt"><groupId></span>io.fluo<span
class="nt"></groupId></span>
<span class="nt"><artifactId></span>fluo-recipes-accumulo<span
class="nt"></artifactId></span>
<span class="nt"><version></span>${fluo-recipes.version}<span
class="nt"></version></span>
<span class="nt"></dependency></span>
- <span class="c"><!--optional dependency assist w/ intergrating Spark
and Fluo --></span>
+ <span class="c"><!--optional dependency assist w/ integrating Spark and
Fluo --></span>
<span class="nt"><dependency></span>
<span class="nt"><groupId></span>io.fluo<span
class="nt"></groupId></span>
<span class="nt"><artifactId></span>fluo-recipes-spark<span
class="nt"></artifactId></span>
<span class="nt"><version></span>${fluo-recipes.version}<span
class="nt"></version></span>
<span class="nt"></dependency></span>
- <span class="c"><!--optional dependency helps when write Fluo
intergeration test. --></span>
+ <span class="c"><!--optional dependency helps when write Fluo
integration test. --></span>
<span class="nt"><dependency></span>
<span class="nt"><groupId></span>io.fluo<span
class="nt"></groupId></span>
<span class="nt"><artifactId></span>fluo-recipes-test<span
class="nt"></artifactId></span>
diff --git a/docs/fluo-recipes/1.0.0-beta-2/table-optimization/index.html
b/docs/fluo-recipes/1.0.0-beta-2/table-optimization/index.html
index a063f31..b329956 100644
--- a/docs/fluo-recipes/1.0.0-beta-2/table-optimization/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-2/table-optimization/index.html
@@ -164,7 +164,7 @@ selective optimizations is need look into using the
following methods instead.</
<h2 id="command-example">Command Example</h2>
<p>Fluo Recipes provides an easy way to optimize a Fluo table for configured
-recipes from the command line. This should be done after configuring reciped
+recipes from the command line. This should be done after configuring recipes
and initializing Fluo. Below are example command for initializing in this
way.</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>
diff --git a/docs/fluo-recipes/1.0.0-beta-2/testing/index.html
b/docs/fluo-recipes/1.0.0-beta-2/testing/index.html
index 454bea4..b703699 100644
--- a/docs/fluo-recipes/1.0.0-beta-2/testing/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-2/testing/index.html
@@ -124,7 +124,7 @@
</header>
<article id="page-content">
- <p>Fluo includes MiniFluo which makes it possible to write an integeration
test that
+ <p>Fluo includes MiniFluo which makes it possible to write an integration
test that
runs against a real Fluo instance. Fluo Recipes provides the following utility
code for writing an integration test.</p>
diff --git a/docs/fluo-recipes/1.0.0-beta-2/transient/index.html
b/docs/fluo-recipes/1.0.0-beta-2/transient/index.html
index be01daf..2dac5ed 100644
--- a/docs/fluo-recipes/1.0.0-beta-2/transient/index.html
+++ b/docs/fluo-recipes/1.0.0-beta-2/transient/index.html
@@ -127,7 +127,7 @@
<h2 id="background">Background</h2>
<p>Some recipes store transient data in a portion of the Fluo table. Transient
-data is data thats continually being added and deleted. Also these transient
+data is data that’s continually being added and deleted. Also these transient
data ranges contain no long term data. The way Fluo works, when data is
deleted a delete marker is inserted but the data is actually still there. Over
time these transient ranges of the table will have a lot more delete markers
@@ -135,7 +135,7 @@ than actual data if nothing is done. If nothing is done,
then processing
transient data will get increasingly slower over time.</p>
<p>These deleted markers can be cleaned up by forcing Accumulo to compact the
-Fluo table, which will run Fluos garbage collection iterator. However,
+Fluo table, which will run Fluo’s garbage collection iterator. However,
compacting the entire table to clean up these ranges within a table is
overkill. Alternatively, Accumulo supports compacting ranges of a table. So
a good solution to the delete marker problem is to periodically compact just
@@ -156,7 +156,7 @@ using this.</p>
<span class="n">transientRegistry</span><span class="o">.</span><span
class="na">addTransientRange</span><span class="o">(</span><span
class="k">new</span> <span class="n">RowRange</span><span
class="o">(</span><span class="n">startRow</span><span class="o">,</span> <span
class="n">endRow</span><span class="o">));</span>
<span class="c1">//Initialize Fluo using fluoConfig. This will store the
registered ranges in</span>
-<span class="c1">//zookeeper making them availiable on any node later.</span>
+<span class="c1">//zookeeper making them available on any node later.</span>
</code></pre></div></div>
<h2 id="compacting-transient-ranges">Compacting Transient Ranges</h2>
@@ -177,7 +177,7 @@ command line using the <code class="highlighter-rouge">fluo
exec</code> command
</code></pre></div></div>
<p>If no arguments are specified the command will call <code
class="highlighter-rouge">compactTransient()</code> once.
-If only <code class="highlighter-rouge"><interval></code> is specied the
command will loop forever calling
+If only <code class="highlighter-rouge"><interval></code> is specified,
the command will loop forever calling
<code class="highlighter-rouge">compactTransient()</code> sleeping <code
class="highlighter-rouge"><interval></code> seconds between calls. If
<code class="highlighter-rouge"><count></code>
is additionally specified then the command will only loop <code
class="highlighter-rouge"><count></code> times.</p>
diff --git a/docs/fluo-recipes/1.0.0-incubating/cfm/index.html
b/docs/fluo-recipes/1.0.0-incubating/cfm/index.html
index 210ee8d..e897be3 100644
--- a/docs/fluo-recipes/1.0.0-incubating/cfm/index.html
+++ b/docs/fluo-recipes/1.0.0-incubating/cfm/index.html
@@ -312,7 +312,7 @@ old value if needed.</p>
<span class="o">}</span>
<span class="k">if</span> <span class="o">(</span><span
class="n">sum</span> <span class="o">==</span> <span class="mi">0</span><span
class="o">)</span> <span class="o">{</span>
- <span class="c1">//returning absent will cause the collision free map
to delte the current key</span>
+ <span class="c1">//returning absent will cause the collision free map
to deletes the current key</span>
<span class="k">return</span> <span class="n">Optional</span><span
class="o">.</span><span class="na">absent</span><span class="o">();</span>
<span class="o">}</span> <span class="k">else</span> <span
class="o">{</span>
<span class="k">return</span> <span class="n">Optional</span><span
class="o">.</span><span class="na">of</span><span class="o">(</span><span
class="n">sum</span><span class="o">);</span>
@@ -353,7 +353,7 @@ calls <code
class="highlighter-rouge">updatingValues()</code> on an <code class=
<ul>
<li>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 <code
class="highlighter-rouge">+1</code> and later
TX2 queues a <code class="highlighter-rouge">-1</code> for the same key, there
is no need to worry about only seeing
diff --git a/docs/fluo-recipes/1.0.0-incubating/export-queue/index.html
b/docs/fluo-recipes/1.0.0-incubating/export-queue/index.html
index f75cbc9..5f2e2aa 100644
--- a/docs/fluo-recipes/1.0.0-incubating/export-queue/index.html
+++ b/docs/fluo-recipes/1.0.0-incubating/export-queue/index.html
@@ -150,7 +150,7 @@ transaction.</p>
<span class="kd">private</span> <span class="kd">static</span> <span
class="kd">final</span> <span class="n">TYPEL</span> <span class="o">=</span>
<span class="k">new</span> <span class="n">TypeLayer</span><span
class="o">(</span><span class="k">new</span> <span
class="n">StringEncoder</span><span class="o">());</span>
- <span class="c1">//reperesents a Query system extrnal to Fluo that is
updated by Fluo</span>
+ <span class="c1">//represents a Query system external to Fluo that is
updated by Fluo</span>
<span class="n">QuerySystem</span> <span class="n">querySystem</span><span
class="o">;</span>
<span class="nd">@Override</span>
@@ -280,7 +280,7 @@ application.</p>
<span class="c1">//initialize Fluo using fluoConfig</span>
</code></pre></div></div>
-<p>Below is updated version of the observer from above thats now using the
export
+<p>Below is updated version of the observer from above that’s now using the
export
queue.</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="kd">public</span> <span
class="kd">class</span> <span class="nc">MyObserver</span> <span
class="kd">extends</span> <span class="n">AbstractObserver</span> <span
class="o">{</span>
@@ -379,7 +379,7 @@ that creates the export value.</p>
<p>In the example above only one transaction will succeed because both are
setting
<code class="highlighter-rouge">row1 fam1:qual1</code>. Since adding to the
export queue is part of the
transaction, only the transaction that succeeds will add something to the
-queue. If the funtion ek() in the example is deterministic, then both
+queue. If the function ek() in the example is deterministic, then both
transactions would have been trying to add the same key to the export
queue.</p>
<p>With the above method, we know that transactions adding entries to the
queue for
@@ -393,7 +393,7 @@ same key. Both transactions succeed because they are
writing to different
cells (<code class="highlighter-rouge">rowB fam1:qual2</code> and <code
class="highlighter-rouge">rowA fam1:qual2</code>). This approach makes it more
difficult to reason about export entries with the same key, because the
transactions adding those entries could have overlapped in time. This is an
-example of write skew mentioned in the Percolater paper.</p>
+example of write skew mentioned in the Percolator paper.</p>
<ol>
<li>TH1 : key1 = ek(<code class="highlighter-rouge">row1</code>,<code
class="highlighter-rouge">fam1:qual1</code>)</li>
diff --git a/docs/fluo-recipes/1.0.0-incubating/table-optimization/index.html
b/docs/fluo-recipes/1.0.0-incubating/table-optimization/index.html
index 65bc348..61586a9 100644
--- a/docs/fluo-recipes/1.0.0-incubating/table-optimization/index.html
+++ b/docs/fluo-recipes/1.0.0-incubating/table-optimization/index.html
@@ -156,7 +156,7 @@ want to use them in production.</p>
<h2 id="command-example">Command Example</h2>
<p>Fluo Recipes provides an easy way to optimize a Fluo table for configured
-recipes from the command line. This should be done after configuring reciped
+recipes from the command line. This should be done after configuring recipes
and initializing Fluo. Below are example command for initializing in this
way.</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>
@@ -174,8 +174,8 @@ fluo <span class="nb">exec </span>app1
org.apache.fluo.recipes.accumulo.cmds.Opt
<h2 id="table-optimization-registry">Table optimization registry</h2>
-<p>Recipes register themself by calling <a
href="https://static.javadoc.io/org.apache.fluo/fluo-recipes-core/1.0.0-incubating/org/apache/fluo/recipes/core/common/TableOptimizations.html";>TableOptimizations.registerOptimization()</a>.
Anyone can use
-this mechanism, its not limited to use by exisitng recipes.</p>
+<p>Recipes register themselves by calling <a
href="https://static.javadoc.io/org.apache.fluo/fluo-recipes-core/1.0.0-incubating/org/apache/fluo/recipes/core/common/TableOptimizations.html";>TableOptimizations.registerOptimization()</a>.
Anyone can use
+this mechanism, its not limited to use by existing recipes.</p>
</article>
diff --git a/docs/fluo-recipes/1.0.0-incubating/testing/index.html
b/docs/fluo-recipes/1.0.0-incubating/testing/index.html
index e29fd70..769f4ed 100644
--- a/docs/fluo-recipes/1.0.0-incubating/testing/index.html
+++ b/docs/fluo-recipes/1.0.0-incubating/testing/index.html
@@ -122,7 +122,7 @@
</header>
<article id="page-content">
- <p>Fluo includes MiniFluo which makes it possible to write an integeration
test that
+ <p>Fluo includes MiniFluo which makes it possible to write an integration
test that
runs against a real Fluo instance. Fluo Recipes provides the following utility
code for writing an integration test.</p>
diff --git a/docs/fluo-recipes/1.0.0-incubating/transient/index.html
b/docs/fluo-recipes/1.0.0-incubating/transient/index.html
index 41ad5ce..acc44d2 100644
--- a/docs/fluo-recipes/1.0.0-incubating/transient/index.html
+++ b/docs/fluo-recipes/1.0.0-incubating/transient/index.html
@@ -125,7 +125,7 @@
<h2 id="background">Background</h2>
<p>Some recipes store transient data in a portion of the Fluo table. Transient
-data is data thats continually being added and deleted. Also these transient
+data is data that’s continually being added and deleted. Also these transient
data ranges contain no long term data. The way Fluo works, when data is
deleted a delete marker is inserted but the data is actually still there. Over
time these transient ranges of the table will have a lot more delete markers
@@ -133,7 +133,7 @@ than actual data if nothing is done. If nothing is done,
then processing
transient data will get increasingly slower over time.</p>
<p>These deleted markers can be cleaned up by forcing Accumulo to compact the
-Fluo table, which will run Fluos garbage collection iterator. However,
+Fluo table, which will run Fluo’s garbage collection iterator. However,
compacting the entire table to clean up these ranges within a table is
overkill. Alternatively, Accumulo supports compacting ranges of a table. So
a good solution to the delete marker problem is to periodically compact just
@@ -154,7 +154,7 @@ using this.</p>
<span class="n">transientRegistry</span><span class="o">.</span><span
class="na">addTransientRange</span><span class="o">(</span><span
class="k">new</span> <span class="n">RowRange</span><span
class="o">(</span><span class="n">startRow</span><span class="o">,</span> <span
class="n">endRow</span><span class="o">));</span>
<span class="c1">//Initialize Fluo using fluoConfig. This will store the
registered ranges in</span>
-<span class="c1">//zookeeper making them availiable on any node later.</span>
+<span class="c1">//zookeeper making them available on any node later.</span>
</code></pre></div></div>
<h2 id="compacting-transient-ranges">Compacting Transient Ranges</h2>
diff --git a/docs/fluo-recipes/1.1.0-incubating/combine-queue/index.html
b/docs/fluo-recipes/1.1.0-incubating/combine-queue/index.html
index aa60d0f..8682d3b 100644
--- a/docs/fluo-recipes/1.1.0-incubating/combine-queue/index.html
+++ b/docs/fluo-recipes/1.1.0-incubating/combine-queue/index.html
@@ -317,7 +317,7 @@ calls <code class="highlighter-rouge">process()</code> on a
<a href="https://sta
<ul>
<li>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 <code
class="highlighter-rouge">+1</code> and later
TX2 queues a <code class="highlighter-rouge">-1</code> for the same key, there
is no need to worry about only seeing
diff --git a/docs/fluo-recipes/1.1.0-incubating/export-queue/index.html
b/docs/fluo-recipes/1.1.0-incubating/export-queue/index.html
index ec2c662..085a91f 100644
--- a/docs/fluo-recipes/1.1.0-incubating/export-queue/index.html
+++ b/docs/fluo-recipes/1.1.0-incubating/export-queue/index.html
@@ -149,7 +149,7 @@ transaction.</p>
<span class="kd">static</span> <span class="kd">final</span> <span
class="n">Column</span> <span class="n">UPDATE_COL</span> <span
class="o">=</span> <span class="k">new</span> <span
class="n">Column</span><span class="o">(</span><span
class="s">"meta"</span><span class="o">,</span> <span
class="s">"numUpdates"</span><span class="o">);</span>
<span class="kd">static</span> <span class="kd">final</span> <span
class="n">Column</span> <span class="n">COUNTER_COL</span> <span
class="o">=</span> <span class="k">new</span> <span
class="n">Column</span><span class="o">(</span><span
class="s">"meta"</span><span class="o">,</span> <span
class="s">"counter1"</span><span class="o">);</span>
- <span class="c1">//reperesents a Query system extrnal to Fluo that is
updated by Fluo</span>
+ <span class="c1">//represents a Query system external to Fluo that is
updated by Fluo</span>
<span class="n">QuerySystem</span> <span class="n">querySystem</span><span
class="o">;</span>
<span class="nd">@Override</span>
@@ -288,7 +288,7 @@ application.</p>
<span class="o">}</span>
</code></pre></div></div>
-<p>Below is updated version of the observer from above thats now using an
export
+<p>Below is updated version of the observer from above that’s now using an
export
queue.</p>
<div class="language-java highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="kd">public</span> <span
class="kd">class</span> <span class="nc">MyObserver</span> <span
class="kd">implements</span> <span class="n">StringObserver</span> <span
class="o">{</span>
@@ -394,7 +394,7 @@ that creates the export value.</p>
<p>In the example above only one transaction will succeed because both are
setting
<code class="highlighter-rouge">row1 fam1:qual1</code>. Since adding to the
export queue is part of the
transaction, only the transaction that succeeds will add something to the
-queue. If the funtion ek() in the example is deterministic, then both
+queue. If the function ek() in the example is deterministic, then both
transactions would have been trying to add the same key to the export
queue.</p>
<p>With the above method, we know that transactions adding entries to the
queue for
@@ -408,7 +408,7 @@ same key. Both transactions succeed because they are
writing to different
cells (<code class="highlighter-rouge">rowB fam1:qual2</code> and <code
class="highlighter-rouge">rowA fam1:qual2</code>). This approach makes it more
difficult to reason about export entries with the same key, because the
transactions adding those entries could have overlapped in time. This is an
-example of write skew mentioned in the Percolater paper.</p>
+example of write skew mentioned in the Percolator paper.</p>
<ol>
<li>TH1 : key1 = ek(<code class="highlighter-rouge">row1</code>,<code
class="highlighter-rouge">fam1:qual1</code>)</li>
diff --git a/docs/fluo-recipes/1.1.0-incubating/table-optimization/index.html
b/docs/fluo-recipes/1.1.0-incubating/table-optimization/index.html
index 5c18ba4..a5b9f18 100644
--- a/docs/fluo-recipes/1.1.0-incubating/table-optimization/index.html
+++ b/docs/fluo-recipes/1.1.0-incubating/table-optimization/index.html
@@ -156,7 +156,7 @@ want to use them in production.</p>
<h2 id="command-example">Command Example</h2>
<p>Fluo Recipes provides an easy way to optimize a Fluo table for configured
-recipes from the command line. This should be done after configuring reciped
+recipes from the command line. This should be done after configuring recipes
and initializing Fluo. Below are example command for initializing in this
way.</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre
class="highlight"><code>
@@ -174,8 +174,8 @@ fluo <span class="nb">exec </span>app1
org.apache.fluo.recipes.accumulo.cmds.Opt
<h2 id="table-optimization-registry">Table optimization registry</h2>
-<p>Recipes register themself by calling <a
href="https://static.javadoc.io/org.apache.fluo/fluo-recipes-core/1.1.0-incubating/org/apache/fluo/recipes/core/common/TableOptimizations.html";>TableOptimizations.registerOptimization()</a>.
Anyone can use
-this mechanism, its not limited to use by exisitng recipes.</p>
+<p>Recipes register themselves by calling <a
href="https://static.javadoc.io/org.apache.fluo/fluo-recipes-core/1.1.0-incubating/org/apache/fluo/recipes/core/common/TableOptimizations.html";>TableOptimizations.registerOptimization()</a>.
Anyone can use
+this mechanism, its not limited to use by existing recipes.</p>
</article>
diff --git a/docs/fluo-recipes/1.1.0-incubating/testing/index.html
b/docs/fluo-recipes/1.1.0-incubating/testing/index.html
index 404395a..88209a3 100644
--- a/docs/fluo-recipes/1.1.0-incubating/testing/index.html
+++ b/docs/fluo-recipes/1.1.0-incubating/testing/index.html
@@ -122,7 +122,7 @@
</header>
<article id="page-content">
- <p>Fluo includes MiniFluo which makes it possible to write an integeration
test that
+ <p>Fluo includes MiniFluo which makes it possible to write an integration
test that
runs against a real Fluo instance. Fluo Recipes provides the following utility
code for writing an integration test.</p>
diff --git a/docs/fluo-recipes/1.1.0-incubating/transient/index.html
b/docs/fluo-recipes/1.1.0-incubating/transient/index.html
index f090c02..a085a77 100644
--- a/docs/fluo-recipes/1.1.0-incubating/transient/index.html
+++ b/docs/fluo-recipes/1.1.0-incubating/transient/index.html
@@ -125,7 +125,7 @@
<h2 id="background">Background</h2>
<p>Some recipes store transient data in a portion of the Fluo table. Transient
-data is data thats continually being added and deleted. Also these transient
+data is data that’s continually being added and deleted. Also these transient
data ranges contain no long term data. The way Fluo works, when data is
deleted a delete marker is inserted but the data is actually still there. Over
time these transient ranges of the table will have a lot more delete markers
@@ -133,7 +133,7 @@ than actual data if nothing is done. If nothing is done,
then processing
transient data will get increasingly slower over time.</p>
<p>These delete markers can be cleaned up by forcing Accumulo to compact the
-Fluo table, which will run Fluos garbage collection iterator. However,
+Fluo table, which will run Fluo’s garbage collection iterator. However,
compacting the entire table to clean up these ranges within a table is
overkill. Alternatively, Accumulo supports compacting ranges of a table. So
a good solution to the delete marker problem is to periodically compact just
@@ -154,7 +154,7 @@ using this.</p>
<span class="n">transientRegistry</span><span class="o">.</span><span
class="na">addTransientRange</span><span class="o">(</span><span
class="k">new</span> <span class="n">RowRange</span><span
class="o">(</span><span class="n">startRow</span><span class="o">,</span> <span
class="n">endRow</span><span class="o">));</span>
<span class="c1">//Initialize Fluo using fluoConfig. This will store the
registered ranges in</span>
-<span class="c1">//zookeeper making them availiable on any node later.</span>
+<span class="c1">//zookeeper making them available on any node later.</span>
</code></pre></div></div>
<h2 id="compacting-transient-ranges">Compacting Transient Ranges</h2>
diff --git a/docs/fluo-recipes/1.2/recipes/combine-queue.html
b/docs/fluo-recipes/1.2/recipes/combine-queue.html
index 3fa7b77..ccef42d 100644
--- a/docs/fluo-recipes/1.2/recipes/combine-queue.html
+++ b/docs/fluo-recipes/1.2/recipes/combine-queue.html
@@ -232,7 +232,7 @@
cause transactions to fail and throughput to nose dive. For example, consider
<a href="https://github.com/astralway/phrasecount";>phrasecount</a>
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 probbaility of collisions is high.</p>
+, the probability of collisions is high.</p>
<h2 id="solution">Solution</h2>
diff --git a/docs/fluo/1.0.0-beta-1/index.html
b/docs/fluo/1.0.0-beta-1/index.html
index 504bb65..f4f5517 100644
--- a/docs/fluo/1.0.0-beta-1/index.html
+++ b/docs/fluo/1.0.0-beta-1/index.html
@@ -123,7 +123,7 @@
</header>
<article id="page-content">
- <p><strong>Fluo is transaction layer that enables incremental processsing
on big data.</strong></p>
+ <p><strong>Fluo is transaction layer that enables incremental processing
on big data.</strong></p>
<p>Fluo is an implementation of <a
href="http://research.google.com/pubs/pub36726.html";>Percolator</a> built on <a
href="http://accumulo.apache.org";>Accumulo</a> that runs in <a
href="http://hadoop.apache.org/docs/r2.5.1/hadoop-yarn/hadoop-yarn-site/YARN.html";>YARN</a>.
It is not recommended for production use yet.</p>
diff --git a/docs/fluo/1.0.0-beta-1/metrics/index.html
b/docs/fluo/1.0.0-beta-1/metrics/index.html
index 650fada..2926878 100644
--- a/docs/fluo/1.0.0-beta-1/metrics/index.html
+++ b/docs/fluo/1.0.0-beta-1/metrics/index.html
@@ -186,7 +186,7 @@ shortened to <code class="highlighter-rouge">i.f</code>.</p>
<p>Since multiple processes can report the same metrics to services like
Graphite
or Ganglia, each process adds a unique id. When running in yarn, this id is of
the format <code class="highlighter-rouge">worker-<instance id></code>
or <code class="highlighter-rouge">oracle-<instance id></code>. When not
running
-from yarn, this id consist of a hostname and a base36 long thats unique across
+from yarn, this id consist of a hostname and a base36 long that’s unique across
all fluo processes. In the table below this composite id is represented with
<code class="highlighter-rouge"><pid></code>.</p>
@@ -222,7 +222,7 @@ all fluo processes. In the table below this composite id
is represented with
<tr>
<td>i.f.<pid>.tx.read.<cn></td>
<td><a
href="https://dropwizard.github.io/metrics/3.1.0/getting-started/#histograms";>Histogram</a></td>
- <td><em>WHEN:</em> After each transaction. <em>WHAT:</em> Number of
row/columns read by transaction that existed. There is currently no count of
all reads (including non-existant data)</td>
+ <td><em>WHEN:</em> After each transaction. <em>WHAT:</em> Number of
row/columns read by transaction that existed. There is currently no count of
all reads (including nonexistent data)</td>
</tr>
<tr>
<td>i.f.<pid>.tx.locks.timedout.<cn></td>
diff --git a/feed.xml b/feed.xml
index 84c1355..37cd28f 100644
--- a/feed.xml
+++ b/feed.xml
@@ -5,8 +5,8 @@
<description>Apache Fluo Website</description>
<link>https://fluo.apache.org//</link>
<atom:link href="https://fluo.apache.org//feed.xml"; rel="self"
type="application/rss+xml" />
- <pubDate>Wed, 09 May 2018 21:43:43 +0000</pubDate>
- <lastBuildDate>Wed, 09 May 2018 21:43:43 +0000</lastBuildDate>
+ <pubDate>Wed, 29 Aug 2018 14:31:58 +0000</pubDate>
+ <lastBuildDate>Wed, 29 Aug 2018 14:31:58 +0000</lastBuildDate>
<generator>Jekyll v3.7.3</generator>
@@ -268,7 +268,7 @@ Accumulo uses, it will not conflict with Fluo’s
version.</p>
<p>Fluo’s commit code is asynchronous in order to support high
throughput.
Before this release the high level commit logic was spread far and wide in the
code. For this release the commit code was transitioned from Guava’s
-ListenableFutre to Java 8’s CompletableFuture in <a
href="https://github.com/apache/fluo/commit/ca63aaf">ca63aaf</a>.
This transition laid
+ListenableFuture to Java 8’s CompletableFuture in <a
href="https://github.com/apache/fluo/commit/ca63aaf">ca63aaf</a>.
This transition laid
the ground work for <a
href="https://github.com/apache/fluo/commit/6bf604f">6bf604f</a>
which centralized the commit logic. Now the high
level logic for the commit code is all in one place, making it much easier to
understand.</p>
diff --git a/release/fluo-1.0.0-alpha-1/index.html
b/release/fluo-1.0.0-alpha-1/index.html
index f785feb..8f5b09e 100644
--- a/release/fluo-1.0.0-alpha-1/index.html
+++ b/release/fluo-1.0.0-alpha-1/index.html
@@ -153,7 +153,7 @@
<h4 id="fluofileoutputformat-and-fluooutputformat">FluoFileOutputFormat and
FluoOutputFormat</h4>
-<p>The FluoFileOuputFormat enables the bulk ingest of a Fluo table using
mapreduce by creating the Accumulo r-files in HDFS. The FluoOutputFormat pushes
keys directly into the Accumulo tablet servers through the client API. <a
href="https://github.com/fluo-io/fluo/issues/35";>Fluo-35</a> added this
feature.</p>
+<p>The FluoFileOutputFormat enables the bulk ingest of a Fluo table using
mapreduce by creating the Accumulo r-files in HDFS. The FluoOutputFormat pushes
keys directly into the Accumulo tablet servers through the client API. <a
href="https://github.com/fluo-io/fluo/issues/35";>Fluo-35</a> added this
feature.</p>
<h4 id="fluo-workers-and-oracle-running-in-yarn">Fluo Workers and Oracle
running in Yarn</h4>
diff --git a/release/fluo-1.2.0/index.html b/release/fluo-1.2.0/index.html
index 0ba0031..9b59efc 100644
--- a/release/fluo-1.2.0/index.html
+++ b/release/fluo-1.2.0/index.html
@@ -278,7 +278,7 @@ Accumulo uses, it will not conflict with Fluo’s version.</p>
<p>Fluo’s commit code is asynchronous in order to support high throughput.
Before this release the high level commit logic was spread far and wide in the
code. For this release the commit code was transitioned from Guava’s
-ListenableFutre to Java 8’s CompletableFuture in <a
href="https://github.com/apache/fluo/commit/ca63aaf";>ca63aaf</a>. This
transition laid
+ListenableFuture to Java 8’s CompletableFuture in <a
href="https://github.com/apache/fluo/commit/ca63aaf";>ca63aaf</a>. This
transition laid
the ground work for <a
href="https://github.com/apache/fluo/commit/6bf604f";>6bf604f</a> which
centralized the commit logic. Now the high
level logic for the commit code is all in one place, making it much easier to
understand.</p>
diff --git a/search_data.json b/search_data.json
index b18ca0c..74f3056 100644
--- a/search_data.json
+++ b/search_data.json
@@ -108,7 +108,7 @@
"docs-fluo-recipes-1-2-recipes-combine-queue": {
"title": "Combine Queue",
- "content" : "BackgroundWhen many transactions try to modify the
same keys, collisions will occur. Too many collisionscause transactions to
fail and throughput to nose dive. For example, consider phrasecountwhich has
many transactions processing documents. Each transaction counts the phrases in
a documentand then updates global phrase counts. Since transaction attempts to
update many phrases, the probbaility of collisions is high.SolutionThe combine
queue recipe provides a reus [...]
+ "content" : "BackgroundWhen many transactions try to modify the
same keys, collisions will occur. Too many collisionscause transactions to
fail and throughput to nose dive. For example, consider phrasecountwhich has
many transactions processing documents. Each transaction counts the phrases in
a documentand then updates global phrase counts. Since transaction attempts to
update many phrases, the probability of collisions is high.SolutionThe combine
queue recipe provides a reus [...]
"url": " /docs/fluo-recipes/1.2/recipes/combine-queue",
"categories": "recipes"
},
@@ -188,7 +188,7 @@
"release-fluo-1-2-0": {
"title": "Apache Fluo 1.2.0",
- "content" : "Apache Fluo is a distributed processing system that
lets users make incrementalupdates to large data sets. With Apache Fluo, users
can set up workflows thatexecute cross node transactions when data changes.
These workflows enable usersto continuously join new data into large existing
data sets withoutreprocessing all data. Apache Fluo is built on Apache
Accumulo.Below are resources for this release: Download a release tarball
and verify by these procedures usin [...]
+ "content" : "Apache Fluo is a distributed processing system that
lets users make incrementalupdates to large data sets. With Apache Fluo, users
can set up workflows thatexecute cross node transactions when data changes.
These workflows enable usersto continuously join new data into large existing
data sets withoutreprocessing all data. Apache Fluo is built on Apache
Accumulo.Below are resources for this release: Download a release tarball
and verify by these procedures usin [...]
"url": " /release/fluo-1.2.0/",
"categories": "release"
}
@@ -340,7 +340,7 @@
"release-fluo-1-0-0-alpha-1": {
"title": "Fluo 1.0.0-alpha-1 released",
- "content" : "Fluo 1.0.0-alpha-1 is the first official release of
Fluo. It contains 83 initial tickets marked for this first milestone. The
roadmap for this release included a working initial implementation, completing
an initial pass at the client API (which will be finalized in 1.0.0), and
writing a stress test application. This release has not been tested much at
scale and is not ready for production use. More scale and performance testing
will be done for the beta release.Bel [...]
+ "content" : "Fluo 1.0.0-alpha-1 is the first official release of
Fluo. It contains 83 initial tickets marked for this first milestone. The
roadmap for this release included a working initial implementation, completing
an initial pass at the client API (which will be finalized in 1.0.0), and
writing a stress test application. This release has not been tested much at
scale and is not ready for production use. More scale and performance testing
will be done for the beta release.Bel [...]
"url": " /release/fluo-1.0.0-alpha-1/",
"categories": "release"
}
