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:41:10 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/87e1e8fc
Tree: http://git-wip-us.apache.org/repos/asf/flink/tree/87e1e8fc
Diff: http://git-wip-us.apache.org/repos/asf/flink/diff/87e1e8fc

Branch: refs/heads/master
Commit: 87e1e8fc350544d81b751efd87f725a1413da1f9
Parents: d1ee819
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:40:04 2017 +0800

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

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.

View raw message