svn commit: r923224 - in /websites/staging/accumulo/trunk/content: ./ release_notes/1.5.2.html

[bu...@apache.org]

Author: buildbot
Date: Tue Sep 23 12:19:58 2014
New Revision: 923224

Log:
Staging update by buildbot for accumulo

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

Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Sep 23 12:19:58 2014
@@ -1 +1 @@
-1626339
+1626983

Modified: websites/staging/accumulo/trunk/content/release_notes/1.5.2.html
==============================================================================
--- websites/staging/accumulo/trunk/content/release_notes/1.5.2.html (original)
+++ websites/staging/accumulo/trunk/content/release_notes/1.5.2.html Tue Sep 23 12:19:58 2014
@@ -208,7 +208,7 @@ over earlier versions in the 1.5 line.</
 <p>Apache Accumulo 1.5.2 includes a number of performance-related fixes over previous versions.</p>
 <h3 id="write-ahead-log-sync-performance">Write-Ahead Log sync performance</h3>
 <p>The Write-Ahead Log (WAL) files are used to ensure durability of updates made to Accumulo.
-A "sync" is called on the file in HDFS to make sure that the changes to the WAL are persisted
+A sync is called on the file in HDFS to make sure that the changes to the WAL are persisted
 to disk, which allows Accumulo to recover in the case of failure. <a href="https://issues.apache.org/jira/browse/ACCUMULO-2766">ACCUMULO-2766</a> fixed
 an issue where an operation against a WAL would unnecessarily wait for multiple syncs, slowing
 down the ingest on the system.</p>
@@ -225,7 +225,7 @@ used is to merge multiple files in HDFS 
 introduces a performance optimization to the HeapIterator which can improve the speed of the
 HeapIterator in common cases.</p>
 <h3 id="write-ahead-log-sync-implementation">Write-Ahead log sync implementation</h3>
-<p>In Hadoop-2, two implementation of "sync" are provider: hflush and hsync. Both of these
+<p>In Hadoop-2, two implementations of sync are provided: hflush and hsync. Both of these
 methods provide a way to request that the datanodes write the data to the underlying
 medium and not just hold it in memory (the 'fsync' syscall). While both of these methods
 inform the Datanodes to sync the relevant block(s), hflush does not wait for acknowledgement
@@ -234,12 +234,12 @@ from the Datanodes that the sync finishe
 a variety of situations (notably, unexpected power outages).</p>
 <p>The downside is that performance tends to suffer because waiting for a sync to disk is a very
 expensive operation. <a href="https://issues.apache.org/jira/browse/ACCUMULO-2842">ACCUMULO-2842</a> introduces a new system property, tserver.wal.sync.method,
-that lets users to change the HDFS sync implementation from 'hsync' to 'hflush'. Using 'hflush' instead
-of 'hsync' should result in about a 30% increase in ingest performance.</p>
-<p>For users upgrading from Hadoop-1 or Hadoop-0.20 releases, "hflush" is the equivalent of how
+that lets users to change the HDFS sync implementation from <em>hsync</em> to <em>hflush</em>. Using <em>hflush</em> instead
+of <em>hsync</em> may result in about a 30% increase in ingest performance.</p>
+<p>For users upgrading from Hadoop-1 or Hadoop-0.20 releases, <em>hflush</em> is the equivalent of how
 sync was implemented and should give equivalent performance.</p>
 <h3 id="server-side-mutation-queue-size">Server-side mutation queue size</h3>
-<p>When users desire writes to be as durable as possible, using 'hsync', the ingest performance
+<p>When users desire writes to be as durable as possible, using <em>hsync</em>, the ingest performance
 of the system can be improved by increasing the tserver.mutation.queue.max property. The cost
 of this change is that it will cause TabletServers to use additional memory per writer. In 1.5.1,
 the value of this parameter defaulted to a conservative 256K, which resulted in sub-par ingest
@@ -258,12 +258,13 @@ due to bad input, where the server would
 buffer and die in the process. <a href="https://issues.apache.org/jira/browse/ACCUMULO-2658">ACCUMULO-2658</a> introduces a configuration
 parameter, like <a href="https://issues.apache.org/jira/browse/ACCUMULO-2360">ACCUMULO-2360</a>, to prevent this error.</p>
 <h3 id="offline-tables-can-prevent-tablet-balancing">Offline tables can prevent tablet balancing</h3>
-<p>A table with many tablets was created, data ingested into it, and then taken
-offline. There were tablet migrations also queued for the table which could not
-happen because the table was offline at that point. The balancer doesn't run
-when there are outstanding migrations; therefore, the system became more and more
-out of balance. <a href="https://issues.apache.org/jira/browse/ACCUMULO-2694">ACCUMULO-2694</a> introduces a fix to ensure that offline tables
-do not block balancing and improves the server-side logging.</p>
+<p>Before 1.5.2, when a table with many tablets was created, ingested into, and
+taken offline, tablet balancing may have stoppped. This would happen if there
+were tablet migrations for the table, because the migrations couldn't occur.
+The balancer will not run when there are outstanding migrations; therefore, a
+system could become unbalanced. <a href="https://issues.apache.org/jira/browse/ACCUMULO-2694">ACCUMULO-2694</a> introduces a fix to ensure
+that offline tables do not block balancing and improves the server-side
+logging.</p>
 <h3 id="miniaccumulocluster-process-management">MiniAccumuloCluster process management</h3>
 <p>MiniAccumuloCluster had a few issues which could cause deadlock or a method that
 never returns. Most of these are related to management of the Accumulo processes