This is an automated email from the ASF dual-hosted git repository. kturner pushed a commit to branch gh-pages in repository https://gitbox.apache.org/repos/asf/fluo-website.git
The following commit(s) were added to refs/heads/gh-pages by this push: new 433b87b update 1.2.0 release notes (#128) 433b87b is described below commit 433b87ba5be06d246ba80232d899f407d8e51b1f Author: Keith Turner <ke...@deenlo.com> AuthorDate: Mon Feb 26 17:55:44 2018 -0500 update 1.2.0 release notes (#128) --- _posts/release/2017-09-22-fluo-1.2.0.md | 83 +++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) 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-- -- To stop receiving notification emails like this one, please contact ktur...@apache.org.