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 <[email protected]>
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
[email protected].
