accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r956093 - in /websites/staging/accumulo/trunk/content: ./ release_notes/1.5.3.html
Date Fri, 26 Jun 2015 18:28:08 GMT
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



Mime
View raw message