svn commit: r956093 - in /websites/staging/accumulo/trunk/content: ./ release_notes/1.5.3.html

[bu...@apache.org]

Author: buildbot
Date: Fri Jun 26 18:28:08 2015
New Revision: 956093

Log:
Staging update by buildbot for accumulo

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

Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Jun 26 18:28:08 2015
@@ -1 +1 @@
-1687827
+1687829

Modified: websites/staging/accumulo/trunk/content/release_notes/1.5.3.html
==============================================================================
--- websites/staging/accumulo/trunk/content/release_notes/1.5.3.html (original)
+++ websites/staging/accumulo/trunk/content/release_notes/1.5.3.html Fri Jun 26 18:28:08 2015
@@ -228,7 +228,7 @@ greatly appreciated.</p>
 <h3 id="sslv3-disabled-poodle"><a href="https://issues.apache.org/jira/browse/ACCUMULO-3316">SSLv3 disabled (POODLE)</a></h3>
 <p>Many Accumulo services were capable of enabling wire encryption using
 SSL connectors. To be safe, <a href="https://issues.apache.org/jira/browse/ACCUMULO-3316">ACCUMULO-3316</a> disables the problematic SSLv3 version by default which was
-potentially susceptible to the man-in-the-middle attack. [ACCUMULO-3317] also disables SSLv3 in the monitor,
+potentially susceptible to the man-in-the-middle attack. <a href="https://issues.apache.org/jira/browse/ACCUMULO-3317">ACCUMULO-3317</a> also disables SSLv3 in the monitor,
 so it will not accept SSLv3 client connections, when running it with https.</p>
 <h2 id="notable-bug-fixes">Notable Bug Fixes</h2>
 <h3 id="sourceswitchingiterator-deadlock"><a href="https://issues.apache.org/jira/browse/ACCUMULO-3745">SourceSwitchingIterator Deadlock</a></h3>
@@ -236,7 +236,7 @@ so it will not accept SSLv3 client conne
 whether data for a tablet read from memory (the in-memory map) or disk (HDFS after a minor
 compaction), was found deadlocked in a production system.</p>
 <p>This deadlock prevented the scan and the minor compaction from ever successfully completing
-without restarting the tablet server. ACCUMULO-3745 fixes the inconsistent synchronization
+without restarting the tablet server. <a href="https://issues.apache.org/jira/browse/ACCUMULO-3745">ACCUMULO-3745</a> fixes the inconsistent synchronization
 inside of the SourceSwitchingIterator to prevent this deadlock from happening in the future.</p>
 <p>The only mitigation of this bug was to restart the tablet server that is deadlocked.</p>
 <h3 id="table-flush-blocked-indefinitely"><a href="https://issues.apache.org/jira/browse/ACCUMULO-3597">Table flush blocked indefinitely</a></h3>
@@ -249,7 +249,7 @@ a deadlock occurred.</p>
 <p>This deadlock happened because the synchronous flush call could not complete before the load
 tablet call completed, but the load tablet call couldn't run because of connection caching we
 perform in Accumulo's RPC layer to reduce the quantity of sockets we need to create to send data.
-ACCUMULO-3597 prevents this deadlock by forcing the use of a non-cached connection for the RPC
+<a href="https://issues.apache.org/jira/browse/ACCUMULO-3597">ACCUMULO-3597</a> prevents this deadlock by forcing the use of a non-cached connection for the RPC
 message requesting a metadata tablet to be loaded.</p>
 <p>While this feature does result in additional network resources to be used, the concern is minimal
 because the number of metadata tablets is typically very small with respect to the total number of