[GitHub] keith-turner closed pull request #128: update 1.2.0 release notes

[GitBox <gi...@apache.org>]

keith-turner closed pull request #128: update 1.2.0 release notes
URL: https://github.com/apache/fluo-website/pull/128
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/_posts/release/2017-09-22-fluo-1.2.0.md b/_posts/release/2017-09-22-fluo-1.2.0.md
index 31db51b..f99410d 100644
--- a/_posts/release/2017-09-22-fluo-1.2.0.md
+++ b/_posts/release/2017-09-22-fluo-1.2.0.md
@@ -42,6 +42,83 @@ refactoring has the following notable changes:
 
 Read the [quickstart documentation][quickstart] to learn how to run Fluo applications using these new methods.
 
+### Fluo now supports read locks.
+
+The Percolator paper stated that read locks were expensive and usually not
+needed.  Therefore in Percolator reads did not acquire a read lock.  This
+assessment is correct, not every read should acquire a read lock.  However,
+offering the ability to optionally obtain a read lock makes writing certain
+applications much simpler.  So in this release of Fluo, optional read locks
+were added. Below is an example of how to acquire read locks.
+
+```java
+  void addEdge(FluoClient client, String node1, String node2) {
+    try(Transaction tx = client.newTransaction()) {
+
+      // These reads acquire a read lock.  Any concurrent changes will cause this
+      // transaction to fail.
+      String a1 = tx.withReadLock().gets(node1, new Column("node","alias"));
+      String a2 = tx.withReadLock().gets(node2, new Column("node","alias"));
+
+      tx.set("e:"+a1+":"+a2, new Column("edge", "exists"), "Y");
+    }
+  }
+
+  void setAlias(FluoClient client, String node, String newAlias) {
+    try(Transaction tx = client.newTransaction()) {
+      String oldAlias = tx.gets(node, new Column("node","alias"));
+      tx.set(node, new Column("node","alias"), newAlias);
+
+      updateExistingEdges(oldAlias, newAlias);
+    }
+  }
+
+```
+
+Concurrent calls to `addEdge(client,"n1","n2")` and `addEdge(client,"n1","n3")`
+can run without issue.  However, concurrent calls to
+`addEdge(client,"n1","n2")` and `setAlias(client, "n1","a5")` will result in a
+collision.  If `addEdge` did not obtain a read lock, then it would not collide
+with `setAlias`.  If `addEdge` obtained a write lock, then concurrent calls to
+`addEdge` could needlessly collide.
+
+See the [withReadLock javadoc][readlock] for more information.
+
+### Asynchronous commit code refactored for readability.
+
+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 [#722].  This transition laid
+the ground work for [#978] 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.
+
+### Addition of Fluo remove command.
+
+Fluo now offers a command to remove an applications data in Zookeeper and
+Accumulo. Work on this issue was done in [#991].
+
+### Shading libthrift
+
+Fluo uses Apache Thrift for remote procedure calls.  Projects using Thrift use
+its compiler to generate code.  This generated Java code make calls to
+libthrift which is an artifact release by the Thrift project.  The code
+generated by a specific version of Thrift is only guaranteed to work with the
+same version of libthrift.  For example, code generated by the Thrift 0.9.1
+compiler is only guaranteed to work with libthrift 0.9.1.
+
+Accumulo also uses Thrift for its RPCs.  When Accumulo and Fluo use different
+versions of thrift it can cause serious problems. To avoid these problems,
+in [#995] libthrift was shaded and relocated into the fluo-core jar eliminating Fluo's
+external dependency on libthrift.  This means that no matter which version
+Accumulo uses, it will not conflict with Fluo's version.
+
+### Minimum Accumulo version.
+
+In [#960] Fluo started using some Accumulo APIs introduced in 1.7.0.  Therefore
+Accumulo 1.7.0 is the minimum supported version of Accumulo.
+
 ## Testing
  
 [procedures]: https://www.apache.org/info/verification
@@ -62,4 +139,10 @@ Read the [quickstart documentation][quickstart] to learn how to run Fluo applica
 [fluo-yarn-release]: https://fluo.apache.org/release/fluo-yarn-1.0.0
 [fluo]: https://github.com/apache/fluo
 [quickstart]: https://fluo.apache.org/docs/fluo/1.2/getting-started/quick-start
+[#722]: https://github.com/apache/fluo/issues/722
 [842]: https://github.com/apache/fluo/issues/842
+[#960]: https://github.com/apache/fluo/issues/960
+[#978]: https://github.com/apache/fluo/issues/978
+[#991]: https://github.com/apache/fluo/issues/991
+[#995]: https://github.com/apache/fluo/issues/995
+[readlock]: {{ site.fluo_api_static }}/{{ site.latest_fluo_release }}/org/apache/fluo/api/client/TransactionBase.html#withReadLock--


 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services