accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r951970 - in /websites/staging/accumulo/trunk/content: ./ release_notes/1.7.0.html
Date Wed, 20 May 2015 02:11:53 GMT
Author: buildbot
Date: Wed May 20 02:11:53 2015
New Revision: 951970

Log:
Staging update by buildbot for accumulo

Modified:
    websites/staging/accumulo/trunk/content/   (props changed)
    websites/staging/accumulo/trunk/content/release_notes/1.7.0.html

Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed May 20 02:11:53 2015
@@ -1 +1 @@
-1680439
+1680440

Modified: websites/staging/accumulo/trunk/content/release_notes/1.7.0.html
==============================================================================
--- websites/staging/accumulo/trunk/content/release_notes/1.7.0.html (original)
+++ websites/staging/accumulo/trunk/content/release_notes/1.7.0.html Wed May 20 02:11:53 2015
@@ -218,11 +218,11 @@ features related to security, availabili
 issues were resolved in this version. Approximately two-thirds were bugs and
 one-third were improvements.</p>
 <p>In the context of Accumulo's <a href="http://semver.org">Semantic Versioning</a>
<a href="https://github.com/apache/accumulo/blob/1.7.0/README.md#api">guidelines</a>,
-this is a "minor version". This means that new APIs have been created, but no
-deprecated APIs have been removed. Code written against 1.6.x should work
-against 1.7.0 (though it may require re-compilation). As always, the Accumulo
-developers take API compatibility very seriously and have invested much time
-to ensure that we meet the promises set forth to our users.</p>
+this is a "minor version". This means that new APIs have been created, some
+deprecations may have been added, but no deprecated APIs have been removed.
+Code written against 1.6.x should work against 1.7.0, likely binary-compatible
+but definitely source-compatible. As always, the Accumulo developers take API compatibility
+very seriously and have invested much time to ensure that we meet the promises set forth
to our users.</p>
 <h1 id="major-changes">Major Changes</h1>
 <h2 id="updated-minimum-requirements">Updated Minimum Requirements</h2>
 <p>Apache Accumulo 1.7.0 comes with an updated set of minimum requirements.</p>
@@ -359,7 +359,7 @@ remove the limitation when sufficient se
 <h2 id="group-commit-threshold-as-a-factor-of-data-size">Group-Commit Threshold as
a Factor of Data Size</h2>
 <p>When ingesting data into Accumulo, the majority of time is spent in the
 write-ahead log. As such, this is a common place that optimizations are added.
-One optimization is the notion of "group-commit". When multiple clients are
+One optimization is known as "group-commit". When multiple clients are
 writing data to the same Accumulo tablet, it is not efficient for each of them
 to synchronize the WAL, flush their updates to disk for durability, and then
 release the lock. The idea of group-commit is that multiple writers can queue
@@ -376,7 +376,7 @@ encouraged sub-par performance with few
 queued before a group-commit is performed in such a way that is agnostic of
 the number of writers. This new configuration property is much easier to
 reason about than the previous (now deprecated) <code>tserver.mutation.queue.max</code>.
-Users who have altered <code>tserver.mutation.queue.max</code> in the past are
encouraged
+Users who have set <code>tserver.mutation.queue.max</code> in the past are encouraged
 to start using the new <code>tserver.total.mutation.queue.max</code> property.</p>
 <h1 id="other-improvements">Other improvements</h1>
 <h2 id="balancing-groups-of-tablets">Balancing Groups of Tablets</h2>



Mime
View raw message