flink-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tzuli...@apache.org
Subject [5/5] flink git commit: [FLINK-6937] [docs] Fix broken link in Production Readiness Checklist
Date Thu, 22 Jun 2017 09:49:56 GMT
[FLINK-6937] [docs] Fix broken link in Production Readiness Checklist

This closes #4134.


Project: http://git-wip-us.apache.org/repos/asf/flink/repo
Commit: http://git-wip-us.apache.org/repos/asf/flink/commit/110eaec9
Tree: http://git-wip-us.apache.org/repos/asf/flink/tree/110eaec9
Diff: http://git-wip-us.apache.org/repos/asf/flink/diff/110eaec9

Branch: refs/heads/release-1.3
Commit: 110eaec9f6cce589dbe4155fe4f818cc4654f5d5
Parents: 3389b34
Author: Juan Paulo Gutierrez <juanpaulo.gutierrez@gmail.com>
Authored: Tue Jun 13 14:31:40 2017 +0900
Committer: Tzu-Li (Gordon) Tai <tzulitai@apache.org>
Committed: Thu Jun 22 17:49:37 2017 +0800

----------------------------------------------------------------------
 docs/ops/production_ready.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/110eaec9/docs/ops/production_ready.md
----------------------------------------------------------------------
diff --git a/docs/ops/production_ready.md b/docs/ops/production_ready.md
index e3e6353..2cce8d0 100644
--- a/docs/ops/production_ready.md
+++ b/docs/ops/production_ready.md
@@ -64,7 +64,7 @@ parallelism as a function of the parallelism when the job is first started:
 
 ### Set UUIDs for operators
 
-As mentioned in the documentation for [savepoints]({{ site.baseurl }}/setup/savepoints.html,
users should set uids for
+As mentioned in the documentation for [savepoints]({{ site.baseurl }}/setup/savepoints.html),
users should set uids for
 operators. Those operator uids are important for Flink's mapping of operator states to operators
which, in turn, is 
 essential for savepoints. By default operator uids are generated by traversing the JobGraph
and hashing certain operator 
 properties. While this is comfortable from a user perspective, it is also very fragile, as
changes to the JobGraph (e.g.
@@ -85,4 +85,4 @@ very important for large states because they do not block the operators
and Flin
 stream processing. However, RocksDB can have worse performance than, for example, the memory-based
state backends. If
 you are sure that your state will never exceed main memory and blocking the stream processing
to write it is not an issue,
 you **could consider** to not use the RocksDB backends. However, at this point, we **strongly
recommend** using RocksDB
-for production.
\ No newline at end of file
+for production.


Mime
View raw message