You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@flink.apache.org by se...@apache.org on 2017/01/16 10:55:24 UTC

[01/10] flink git commit: [hotfix] [docs] Move 'dev/state_backends' to 'ops/state_backends'

Repository: flink
Updated Branches:
  refs/heads/release-1.2 33c5df6dd -> f4869a66d


[hotfix] [docs] Move 'dev/state_backends' to 'ops/state_backends'


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

Branch: refs/heads/release-1.2
Commit: daad28ab5431ba1ab280a2024b5d28b70b0713ee
Parents: 33c5df6
Author: Stephan Ewen <se...@apache.org>
Authored: Mon Jan 9 19:39:44 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:52:41 2017 +0100

----------------------------------------------------------------------
 docs/dev/state.md                |   4 +-
 docs/dev/state_backends.md       | 148 ----------------------------------
 docs/ops/README.md               |  21 +++++
 docs/ops/state_backends.md       | 148 ++++++++++++++++++++++++++++++++++
 docs/redirects/state_backends.md |   2 +-
 docs/setup/aws.md                |   4 +-
 docs/setup/savepoints.md         |   2 +-
 7 files changed, 175 insertions(+), 154 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/daad28ab/docs/dev/state.md
----------------------------------------------------------------------
diff --git a/docs/dev/state.md b/docs/dev/state.md
index 73a4ceb..4478bfc 100644
--- a/docs/dev/state.md
+++ b/docs/dev/state.md
@@ -40,7 +40,7 @@ Flink's state interface.
 By default state checkpoints will be stored in-memory at the JobManager. For proper persistence of large
 state, Flink supports storing the checkpoints on file systems (HDFS, S3, or any mounted POSIX file system),
 which can be configured in the `flink-conf.yaml` or via `StreamExecutionEnvironment.setStateBackend(\u2026)`.
-See [state backends]({{ site.baseurl }}/dev/state_backends.html) for information
+See [state backends]({{ site.baseurl }}/ops/state_backends.html) for information
 about the available state backends and how to configure them.
 
 * ToC
@@ -52,7 +52,7 @@ Enabling Checkpointing
 Flink has a checkpointing mechanism that recovers streaming jobs after failures. The checkpointing mechanism requires a *persistent* (or *durable*) source that
 can be asked for prior records again (Apache Kafka is a good example of such a source).
 
-The checkpointing mechanism stores the progress in the data sources and data sinks, the state of windows, as well as the user-defined state (see [Working with State]({{ site.baseurl }}/dev/state.html)) consistently to provide *exactly once* processing semantics. Where the checkpoints are stored (e.g., JobManager memory, file system, database) depends on the configured [state backend]({{ site.baseurl }}/dev/state_backends.html).
+The checkpointing mechanism stores the progress in the data sources and data sinks, the state of windows, as well as the user-defined state (see [Working with State]({{ site.baseurl }}/dev/state.html)) consistently to provide *exactly once* processing semantics. Where the checkpoints are stored (e.g., JobManager memory, file system, database) depends on the configured [state backend]({{ site.baseurl }}/ops/state_backends.html).
 
 The [docs on streaming fault tolerance]({{ site.baseurl }}/internals/stream_checkpointing.html) describe in detail the technique behind Flink's streaming fault tolerance mechanism.
 

http://git-wip-us.apache.org/repos/asf/flink/blob/daad28ab/docs/dev/state_backends.md
----------------------------------------------------------------------
diff --git a/docs/dev/state_backends.md b/docs/dev/state_backends.md
deleted file mode 100644
index af9934d..0000000
--- a/docs/dev/state_backends.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: "State Backends"
-nav-parent_id: setup
-nav-pos: 11
----
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-Programs written in the [Data Stream API]({{ site.baseurl }}/dev/datastream_api.html) often hold state in various forms:
-
-- Windows gather elements or aggregates until they are triggered
-- Transformation functions may use the key/value state interface to store values
-- Transformation functions may implement the `Checkpointed` interface to make their local variables fault tolerant
-
-See also [Working with State]({{ site.baseurl }}/dev/state.html) in the streaming API guide.
-
-When checkpointing is activated, such state is persisted upon checkpoints to guard against data loss and recover consistently.
-How the state is represented internally, and how and where it is persisted upon checkpoints depends on the
-chosen **State Backend**.
-
-* ToC
-{:toc}
-
-## Available State Backends
-
-Out of the box, Flink bundles these state backends:
-
- - *MemoryStateBackend*
- - *FsStateBackend*
- - *RocksDBStateBackend*
-
-If nothing else is configured, the system will use the MemoryStateBackend.
-
-
-### The MemoryStateBackend
-
-The *MemoryStateBackend* holds data internally as objects on the Java heap. Key/value state and window operators hold hash tables
-that store the values, triggers, etc.
-
-Upon checkpoints, this state backend will snapshot the state and send it as part of the checkpoint acknowledgement messages to the
-JobManager (master), which stores it on its heap as well.
-
-Limitations of the MemoryStateBackend:
-
-  - The size of each individual state is by default limited to 5 MB. This value can be increased in the constructor of the MemoryStateBackend.
-  - Irrespective of the configured maximal state size, the state cannot be larger than the akka frame size (see [Configuration]({{ site.baseurl }}/setup/config.html)).
-  - The aggregate state must fit into the JobManager memory.
-
-The MemoryStateBackend is encouraged for:
-
-  - Local development and debugging
-  - Jobs that do hold little state, such as jobs that consist only of record-at-a-time functions (Map, FlatMap, Filter, ...). The Kafka Consumer requires very little state.
-
-
-### The FsStateBackend
-
-The *FsStateBackend* is configured with a file system URL (type, address, path), such as "hdfs://namenode:40010/flink/checkpoints" or "file:///data/flink/checkpoints".
-
-The FsStateBackend holds in-flight data in the TaskManager's memory. Upon checkpointing, it writes state snapshots into files in the configured file system and directory. Minimal metadata is stored in the JobManager's memory (or, in high-availability mode, in the metadata checkpoint).
-
-The FsStateBackend is encouraged for:
-
-  - Jobs with large state, long windows, large key/value states.
-  - All high-availability setups.
-
-### The RocksDBStateBackend
-
-The *RocksDBStateBackend* is configured with a file system URL (type, address, path), such as "hdfs://namenode:40010/flink/checkpoints" or "file:///data/flink/checkpoints".
-
-The RocksDBStateBackend holds in-flight data in a [RocksDB](http://rocksdb.org) data base
-that is (per default) stored in the TaskManager data directories. Upon checkpointing, the whole
-RocksDB data base will be checkpointed into the configured file system and directory. Minimal
-metadata is stored in the JobManager's memory (or, in high-availability mode, in the metadata checkpoint).
-
-The RocksDBStateBackend is encouraged for:
-
-  - Jobs with very large state, long windows, large key/value states.
-  - All high-availability setups.
-
-Note that the amount of state that you can keep is only limited by the amount of disc space available.
-This allows keeping very large state, compared to the FsStateBackend that keeps state in memory.
-This also means, however, that the maximum throughput that can be achieved will be lower with
-this state backend.
-
-## Configuring a State Backend
-
-State backends can be configured per job. In addition, you can define a default state backend to be used when the
-job does not explicitly define a state backend.
-
-
-### Setting the Per-job State Backend
-
-The per-job state backend is set on the `StreamExecutionEnvironment` of the job, as shown in the example below:
-
-<div class="codetabs" markdown="1">
-<div data-lang="java" markdown="1">
-{% highlight java %}
-StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
-env.setStateBackend(new FsStateBackend("hdfs://namenode:40010/flink/checkpoints"));
-{% endhighlight %}
-</div>
-<div data-lang="scala" markdown="1">
-{% highlight scala %}
-val env = StreamExecutionEnvironment.getExecutionEnvironment()
-env.setStateBackend(new FsStateBackend("hdfs://namenode:40010/flink/checkpoints"))
-{% endhighlight %}
-</div>
-</div>
-
-
-### Setting Default State Backend
-
-A default state backend can be configured in the `flink-conf.yaml`, using the configuration key `state.backend`.
-
-Possible values for the config entry are *jobmanager* (MemoryStateBackend), *filesystem* (FsStateBackend), or the fully qualified class
-name of the class that implements the state backend factory [FsStateBackendFactory](https://github.com/apache/flink/blob/master/flink-runtime/src/main/java/org/apache/flink/runtime/state/filesystem/FsStateBackendFactory.java),
-such as `org.apache.flink.contrib.streaming.state.RocksDBStateBackendFactory` for RocksDBStateBackend.
-
-In the case where the default state backend is set to *filesystem*, the entry `state.backend.fs.checkpointdir` defines the directory where the checkpoint data will be stored.
-
-A sample section in the configuration file could look as follows:
-
-~~~
-# The backend that will be used to store operator state checkpoints
-
-state.backend: filesystem
-
-
-# Directory for storing checkpoints
-
-state.backend.fs.checkpointdir: hdfs://namenode:40010/flink/checkpoints
-~~~

http://git-wip-us.apache.org/repos/asf/flink/blob/daad28ab/docs/ops/README.md
----------------------------------------------------------------------
diff --git a/docs/ops/README.md b/docs/ops/README.md
new file mode 100644
index 0000000..5fe6568
--- /dev/null
+++ b/docs/ops/README.md
@@ -0,0 +1,21 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+This folder contains the documentation in the category
+**Deployment & Operations**.

http://git-wip-us.apache.org/repos/asf/flink/blob/daad28ab/docs/ops/state_backends.md
----------------------------------------------------------------------
diff --git a/docs/ops/state_backends.md b/docs/ops/state_backends.md
new file mode 100644
index 0000000..af9934d
--- /dev/null
+++ b/docs/ops/state_backends.md
@@ -0,0 +1,148 @@
+---
+title: "State Backends"
+nav-parent_id: setup
+nav-pos: 11
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+Programs written in the [Data Stream API]({{ site.baseurl }}/dev/datastream_api.html) often hold state in various forms:
+
+- Windows gather elements or aggregates until they are triggered
+- Transformation functions may use the key/value state interface to store values
+- Transformation functions may implement the `Checkpointed` interface to make their local variables fault tolerant
+
+See also [Working with State]({{ site.baseurl }}/dev/state.html) in the streaming API guide.
+
+When checkpointing is activated, such state is persisted upon checkpoints to guard against data loss and recover consistently.
+How the state is represented internally, and how and where it is persisted upon checkpoints depends on the
+chosen **State Backend**.
+
+* ToC
+{:toc}
+
+## Available State Backends
+
+Out of the box, Flink bundles these state backends:
+
+ - *MemoryStateBackend*
+ - *FsStateBackend*
+ - *RocksDBStateBackend*
+
+If nothing else is configured, the system will use the MemoryStateBackend.
+
+
+### The MemoryStateBackend
+
+The *MemoryStateBackend* holds data internally as objects on the Java heap. Key/value state and window operators hold hash tables
+that store the values, triggers, etc.
+
+Upon checkpoints, this state backend will snapshot the state and send it as part of the checkpoint acknowledgement messages to the
+JobManager (master), which stores it on its heap as well.
+
+Limitations of the MemoryStateBackend:
+
+  - The size of each individual state is by default limited to 5 MB. This value can be increased in the constructor of the MemoryStateBackend.
+  - Irrespective of the configured maximal state size, the state cannot be larger than the akka frame size (see [Configuration]({{ site.baseurl }}/setup/config.html)).
+  - The aggregate state must fit into the JobManager memory.
+
+The MemoryStateBackend is encouraged for:
+
+  - Local development and debugging
+  - Jobs that do hold little state, such as jobs that consist only of record-at-a-time functions (Map, FlatMap, Filter, ...). The Kafka Consumer requires very little state.
+
+
+### The FsStateBackend
+
+The *FsStateBackend* is configured with a file system URL (type, address, path), such as "hdfs://namenode:40010/flink/checkpoints" or "file:///data/flink/checkpoints".
+
+The FsStateBackend holds in-flight data in the TaskManager's memory. Upon checkpointing, it writes state snapshots into files in the configured file system and directory. Minimal metadata is stored in the JobManager's memory (or, in high-availability mode, in the metadata checkpoint).
+
+The FsStateBackend is encouraged for:
+
+  - Jobs with large state, long windows, large key/value states.
+  - All high-availability setups.
+
+### The RocksDBStateBackend
+
+The *RocksDBStateBackend* is configured with a file system URL (type, address, path), such as "hdfs://namenode:40010/flink/checkpoints" or "file:///data/flink/checkpoints".
+
+The RocksDBStateBackend holds in-flight data in a [RocksDB](http://rocksdb.org) data base
+that is (per default) stored in the TaskManager data directories. Upon checkpointing, the whole
+RocksDB data base will be checkpointed into the configured file system and directory. Minimal
+metadata is stored in the JobManager's memory (or, in high-availability mode, in the metadata checkpoint).
+
+The RocksDBStateBackend is encouraged for:
+
+  - Jobs with very large state, long windows, large key/value states.
+  - All high-availability setups.
+
+Note that the amount of state that you can keep is only limited by the amount of disc space available.
+This allows keeping very large state, compared to the FsStateBackend that keeps state in memory.
+This also means, however, that the maximum throughput that can be achieved will be lower with
+this state backend.
+
+## Configuring a State Backend
+
+State backends can be configured per job. In addition, you can define a default state backend to be used when the
+job does not explicitly define a state backend.
+
+
+### Setting the Per-job State Backend
+
+The per-job state backend is set on the `StreamExecutionEnvironment` of the job, as shown in the example below:
+
+<div class="codetabs" markdown="1">
+<div data-lang="java" markdown="1">
+{% highlight java %}
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+env.setStateBackend(new FsStateBackend("hdfs://namenode:40010/flink/checkpoints"));
+{% endhighlight %}
+</div>
+<div data-lang="scala" markdown="1">
+{% highlight scala %}
+val env = StreamExecutionEnvironment.getExecutionEnvironment()
+env.setStateBackend(new FsStateBackend("hdfs://namenode:40010/flink/checkpoints"))
+{% endhighlight %}
+</div>
+</div>
+
+
+### Setting Default State Backend
+
+A default state backend can be configured in the `flink-conf.yaml`, using the configuration key `state.backend`.
+
+Possible values for the config entry are *jobmanager* (MemoryStateBackend), *filesystem* (FsStateBackend), or the fully qualified class
+name of the class that implements the state backend factory [FsStateBackendFactory](https://github.com/apache/flink/blob/master/flink-runtime/src/main/java/org/apache/flink/runtime/state/filesystem/FsStateBackendFactory.java),
+such as `org.apache.flink.contrib.streaming.state.RocksDBStateBackendFactory` for RocksDBStateBackend.
+
+In the case where the default state backend is set to *filesystem*, the entry `state.backend.fs.checkpointdir` defines the directory where the checkpoint data will be stored.
+
+A sample section in the configuration file could look as follows:
+
+~~~
+# The backend that will be used to store operator state checkpoints
+
+state.backend: filesystem
+
+
+# Directory for storing checkpoints
+
+state.backend.fs.checkpointdir: hdfs://namenode:40010/flink/checkpoints
+~~~

http://git-wip-us.apache.org/repos/asf/flink/blob/daad28ab/docs/redirects/state_backends.md
----------------------------------------------------------------------
diff --git a/docs/redirects/state_backends.md b/docs/redirects/state_backends.md
index f575111..3a21aaa 100644
--- a/docs/redirects/state_backends.md
+++ b/docs/redirects/state_backends.md
@@ -1,7 +1,7 @@
 ---
 title: "State Backends"
 layout: redirect
-redirect: /dev/state_backends.html
+redirect: /ops/state_backends.html
 permalink: /apis/streaming/state_backends.html
 ---
 <!--

http://git-wip-us.apache.org/repos/asf/flink/blob/daad28ab/docs/setup/aws.md
----------------------------------------------------------------------
diff --git a/docs/setup/aws.md b/docs/setup/aws.md
index 83b5d97..d165955 100644
--- a/docs/setup/aws.md
+++ b/docs/setup/aws.md
@@ -57,7 +57,7 @@ HADOOP_CONF_DIR=/etc/hadoop/conf bin/flink run -m yarn-cluster examples/streamin
 
 ## S3: Simple Storage Service
 
-[Amazon Simple Storage Service](http://aws.amazon.com/s3/) (Amazon S3) provides cloud object storage for a variety of use cases. You can use S3 with Flink for **reading** and **writing data** as well in conjunction with the [streaming **state backends**]({{ site.baseurl}}/dev/state_backends.html).
+[Amazon Simple Storage Service](http://aws.amazon.com/s3/) (Amazon S3) provides cloud object storage for a variety of use cases. You can use S3 with Flink for **reading** and **writing data** as well in conjunction with the [streaming **state backends**]({{ site.baseurl}}/ops/state_backends.html).
 
 You can use S3 objects like regular files by specifying paths in the following format:
 
@@ -78,7 +78,7 @@ stream.writeAsText("s3://<bucket>/<endpoint>");
 env.setStateBackend(new FsStateBackend("s3://<your-bucket>/<endpoint>"));
 ```
 
-Note that these examples are *not* exhaustive and you can use S3 in other places as well, including your [high availability setup]({{ site.baseurl }}/setup/jobmanager_high_availability.html) or the [RocksDBStateBackend]({{ site.baseurl }}/dev/state_backends.html#the-rocksdbstatebackend);  everywhere that Flink expects a FileSystem URI.
+Note that these examples are *not* exhaustive and you can use S3 in other places as well, including your [high availability setup]({{ site.baseurl }}/setup/jobmanager_high_availability.html) or the [RocksDBStateBackend]({{ site.baseurl }}/ops/state_backends.html#the-rocksdbstatebackend);  everywhere that Flink expects a FileSystem URI.
 
 ### Set S3 FileSystem
 

http://git-wip-us.apache.org/repos/asf/flink/blob/daad28ab/docs/setup/savepoints.md
----------------------------------------------------------------------
diff --git a/docs/setup/savepoints.md b/docs/setup/savepoints.md
index 2866635..2a1f631 100644
--- a/docs/setup/savepoints.md
+++ b/docs/setup/savepoints.md
@@ -22,7 +22,7 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-Programs written in the [Data Stream API](index.html) can resume execution from a **savepoint**. Savepoints allow both updating your programs and your Flink cluster without losing any state. This page covers all steps to trigger, restore, and dispose savepoints. For more details on how Flink handles state and failures, check out the [State in Streaming Programs]({{ site.baseurl }}/dev/state_backends.html) and [Fault Tolerance](fault_tolerance.html) pages.
+Programs written in the [Data Stream API](index.html) can resume execution from a **savepoint**. Savepoints allow both updating your programs and your Flink cluster without losing any state. This page covers all steps to trigger, restore, and dispose savepoints. For more details on how Flink handles state and failures, check out the [State in Streaming Programs]({{ site.baseurl }}/ops/state_backends.html) and [Fault Tolerance](fault_tolerance.html) pages.
 
 * toc
 {:toc}

[06/10] flink git commit: [FLINK-5457] [docs] Add stub for Async I/O docs

Posted by se...@apache.org.

[FLINK-5457] [docs] Add stub for Async I/O docs


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

Branch: refs/heads/release-1.2
Commit: 2730e895fc87970f509ff8297222d6791fd31fdf
Parents: 5850953
Author: Stephan Ewen <se...@apache.org>
Authored: Tue Jan 10 12:36:51 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:53:36 2017 +0100

----------------------------------------------------------------------
 docs/dev/stream/asyncio.md | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/2730e895/docs/dev/stream/asyncio.md
----------------------------------------------------------------------
diff --git a/docs/dev/stream/asyncio.md b/docs/dev/stream/asyncio.md
new file mode 100644
index 0000000..2d0867a
--- /dev/null
+++ b/docs/dev/stream/asyncio.md
@@ -0,0 +1,28 @@
+---
+title: "Async I/O for External Data Access"
+nav-parent_id: streaming
+nav-pos: 60
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+* ToC
+{:toc}
+
+**TDB**

[08/10] flink git commit: [FLINK-5459] [docs] Add templates for debugging classloading and debugging event time issues

Posted by se...@apache.org.

[FLINK-5459] [docs] Add templates for debugging classloading and debugging event time issues


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

Branch: refs/heads/release-1.2
Commit: ef185d777d6c5debf139833b6af88e9cbfa583bf
Parents: 4b0c4d9
Author: Stephan Ewen <se...@apache.org>
Authored: Tue Jan 10 22:56:16 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:53:55 2017 +0100

----------------------------------------------------------------------
 docs/monitoring/debugging_classloading.md | 45 ++++++++++++++++++++++++++
 docs/monitoring/debugging_event_time.md   | 37 +++++++++++++++++++++
 2 files changed, 82 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/ef185d77/docs/monitoring/debugging_classloading.md
----------------------------------------------------------------------
diff --git a/docs/monitoring/debugging_classloading.md b/docs/monitoring/debugging_classloading.md
new file mode 100644
index 0000000..e4e908e
--- /dev/null
+++ b/docs/monitoring/debugging_classloading.md
@@ -0,0 +1,45 @@
+---
+title: "Debugging Classloading"
+nav-parent_id: monitoring
+nav-pos: 8
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+* ToC
+{:toc}
+
+## Overview of Classloading in Flink
+
+  - What is in the Application Classloader for different deployment techs
+  - What is in the user code classloader
+
+  - Access to the user code classloader for applications
+
+## Classpath Setups
+
+  - Finding classpaths in logs
+  - Moving libraries and/or user code to the Application Classpath 
+
+## Unloading of Dynamically Loaded Classes
+
+  - Checkpoint statistics overview
+  - Interpret time until checkpoints
+  - Synchronous vs. asynchronous checkpoint time
+

http://git-wip-us.apache.org/repos/asf/flink/blob/ef185d77/docs/monitoring/debugging_event_time.md
----------------------------------------------------------------------
diff --git a/docs/monitoring/debugging_event_time.md b/docs/monitoring/debugging_event_time.md
new file mode 100644
index 0000000..e87db0a
--- /dev/null
+++ b/docs/monitoring/debugging_event_time.md
@@ -0,0 +1,37 @@
+---
+title: "Debugging Windows & Event Time"
+nav-parent_id: monitoring
+nav-pos: 9
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+* ToC
+{:toc}
+
+## Monitoring Current Event Time
+
+  - What metrics, how to access in the UI
+  - Event time dominated by furthest-behind source
+
+## Handling Event Time Stragglers
+
+  - Approach 1: Watermark stays late (indicated completeness), windows fire early
+  - Approach 2: Watermark heuristic with maximum lateness, windows accept late data
+

[09/10] flink git commit: [FLINK-5460] [docs] Add placeholder for Docker setup guide

Posted by se...@apache.org.

[FLINK-5460] [docs] Add placeholder for Docker setup guide


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

Branch: refs/heads/release-1.2
Commit: b41d0ff8ffa6286a6040bae44ccaf2d4082708c5
Parents: ef185d7
Author: Stephan Ewen <se...@apache.org>
Authored: Tue Jan 10 23:04:52 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:54:04 2017 +0100

----------------------------------------------------------------------
 docs/setup/aws.md        |  2 +-
 docs/setup/deployment.md |  2 +-
 docs/setup/docker.md     | 29 +++++++++++++++++++++++++++++
 docs/setup/gce_setup.md  |  2 +-
 4 files changed, 32 insertions(+), 3 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/b41d0ff8/docs/setup/aws.md
----------------------------------------------------------------------
diff --git a/docs/setup/aws.md b/docs/setup/aws.md
index d165955..8d04d59 100644
--- a/docs/setup/aws.md
+++ b/docs/setup/aws.md
@@ -2,7 +2,7 @@
 title: "Amazon Web Services (AWS)"
 nav-title: AWS
 nav-parent_id: deployment
-nav-pos: 4
+nav-pos: 10
 ---
 <!--
 Licensed to the Apache Software Foundation (ASF) under one

http://git-wip-us.apache.org/repos/asf/flink/blob/b41d0ff8/docs/setup/deployment.md
----------------------------------------------------------------------
diff --git a/docs/setup/deployment.md b/docs/setup/deployment.md
index f3c8005..416106b 100644
--- a/docs/setup/deployment.md
+++ b/docs/setup/deployment.md
@@ -1,5 +1,5 @@
 ---
-title: "Deployment"
+title: "Clusters & Deployment"
 nav-id: deployment
 nav-parent_id: setup
 nav-pos: 5

http://git-wip-us.apache.org/repos/asf/flink/blob/b41d0ff8/docs/setup/docker.md
----------------------------------------------------------------------
diff --git a/docs/setup/docker.md b/docs/setup/docker.md
new file mode 100644
index 0000000..8b9757f
--- /dev/null
+++ b/docs/setup/docker.md
@@ -0,0 +1,29 @@
+---
+title:  "Docker Setup"
+nav-title: Docker
+nav-parent_id: deployment
+nav-pos: 4
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+* This will be replaced by the TOC
+{:toc}
+
+

http://git-wip-us.apache.org/repos/asf/flink/blob/b41d0ff8/docs/setup/gce_setup.md
----------------------------------------------------------------------
diff --git a/docs/setup/gce_setup.md b/docs/setup/gce_setup.md
index de38ce4..f9edfcc 100644
--- a/docs/setup/gce_setup.md
+++ b/docs/setup/gce_setup.md
@@ -2,7 +2,7 @@
 title:  "Google Compute Engine Setup"
 nav-title: Google Compute Engine
 nav-parent_id: deployment
-nav-pos: 5
+nav-pos: 20
 ---
 <!--
 Licensed to the Apache Software Foundation (ASF) under one

[02/10] flink git commit: [FLINK-5454] [docs] Add stub for docs on "Tuning for large state"

Posted by se...@apache.org.

[FLINK-5454] [docs] Add stub for docs on "Tuning for large state"


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

Branch: refs/heads/release-1.2
Commit: 7aad7514ab8c9c371d02b8e4641c64e4d460d78d
Parents: daad28a
Author: Stephan Ewen <se...@apache.org>
Authored: Mon Jan 9 20:01:38 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:52:50 2017 +0100

----------------------------------------------------------------------
 docs/monitoring/README.md             | 21 ++++++++++
 docs/monitoring/large_state_tuning.md | 62 ++++++++++++++++++++++++++++++
 docs/monitoring/rest_api.md           |  2 +-
 3 files changed, 84 insertions(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/7aad7514/docs/monitoring/README.md
----------------------------------------------------------------------
diff --git a/docs/monitoring/README.md b/docs/monitoring/README.md
new file mode 100644
index 0000000..88c6509
--- /dev/null
+++ b/docs/monitoring/README.md
@@ -0,0 +1,21 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+This folder contains the documentation in the category
+**Debugging & Monitoring**.

http://git-wip-us.apache.org/repos/asf/flink/blob/7aad7514/docs/monitoring/large_state_tuning.md
----------------------------------------------------------------------
diff --git a/docs/monitoring/large_state_tuning.md b/docs/monitoring/large_state_tuning.md
new file mode 100644
index 0000000..c49c106
--- /dev/null
+++ b/docs/monitoring/large_state_tuning.md
@@ -0,0 +1,62 @@
+---
+title: "Debugging and Tuning Checkpoints and Large State"
+nav-parent_id: monitoring
+nav-pos: 5
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+This page gives a guide how to improve and tune applications that use large state.
+
+* ToC
+{:toc}
+
+## Monitoring State and Checkpoints
+
+  - Checkpoint statistics overview
+  - Interpret time until checkpoints
+  - Synchronous vs. asynchronous checkpoint time
+
+## Tuning Checkpointing
+
+  - Checkpoint interval
+  - Getting work done between checkpoints (min time between checkpoints)
+
+## Tuning Network Buffers
+
+  - getting a good number of buffers to use
+  - monitoring if too many buffers cause too much inflight data
+
+## Make checkpointing asynchronous where possible
+
+  - large state should be on keyed state, not operator state, because keyed state is managed, operator state not (subject to change in future versions)
+
+  - asynchronous snapshots preferrable. long synchronous snapshot times can cause problems on large state and complex topogies. move to RocksDB for that
+
+## Tuning RocksDB
+
+  - Predefined options
+  - Custom Options
+
+## Capacity planning
+
+  - Normal operation should not be constantly back pressured (link to back pressure monitor)
+  - Allow for some excess capacity to support catch-up in case of failures and checkpoint alignment skew (due to data skew or bad nodes)
+
+

http://git-wip-us.apache.org/repos/asf/flink/blob/7aad7514/docs/monitoring/rest_api.md
----------------------------------------------------------------------
diff --git a/docs/monitoring/rest_api.md b/docs/monitoring/rest_api.md
index 2da3726..d49dece 100644
--- a/docs/monitoring/rest_api.md
+++ b/docs/monitoring/rest_api.md
@@ -1,7 +1,7 @@
 ---
 title:  "Monitoring REST API"
 nav-parent_id: monitoring
-nav-pos: 3
+nav-pos: 10
 ---
 <!--
 Licensed to the Apache Software Foundation (ASF) under one

[07/10] flink git commit: [FLINK-5458] [docs] Add a template for migration guide

Posted by se...@apache.org.

[FLINK-5458] [docs] Add a template for migration guide


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

Branch: refs/heads/release-1.2
Commit: 4b0c4d969e53caa986a47465c3600484dbd14e5e
Parents: 2730e89
Author: Stephan Ewen <se...@apache.org>
Authored: Tue Jan 10 15:44:42 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:53:46 2017 +0100

----------------------------------------------------------------------
 docs/dev/migration.md | 33 +++++++++++++++++++++++++++++++++
 docs/index.md         | 11 ++++++++++-
 2 files changed, 43 insertions(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/4b0c4d96/docs/dev/migration.md
----------------------------------------------------------------------
diff --git a/docs/dev/migration.md b/docs/dev/migration.md
new file mode 100644
index 0000000..c74952c
--- /dev/null
+++ b/docs/dev/migration.md
@@ -0,0 +1,33 @@
+---
+title: "API Migration Guides"
+nav-parent_id: dev
+nav-pos: 100
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+* This will be replaced by the TOC
+{:toc}
+
+## Flink 1.1 to 1.2
+
+### State API
+
+### Fast Processing Time Window Operators
+

http://git-wip-us.apache.org/repos/asf/flink/blob/4b0c4d96/docs/index.md
----------------------------------------------------------------------
diff --git a/docs/index.md b/docs/index.md
index 75b5328..595a094 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -29,8 +29,17 @@ Apache Flink is an open source platform for distributed stream and batch data pr
 
 ## First Steps
 
-- **Concepts**: Start with the basic concepts of Flink's [Dataflow Programming Model]({{ site.baseurl }}/concepts/programming-model.html) and [Distributed Runtime Environment]({{ site.baseurl }}/concepts/runtime.html). This will help you to fully understand the other parts of the documentation, including the setup and programming guides. It is highly recommended to read these sections first.
+- **Concepts**: Start with the basic concepts of Flink's [Dataflow Programming Model](concepts/programming-model.html) and [Distributed Runtime Environment](concepts/runtime.html). This will help you to fully understand the other parts of the documentation, including the setup and programming guides. It is highly recommended to read these sections first.
 
 - **Quickstarts**: [Run an example program](quickstart/setup_quickstart.html) on your local machine or [write a simple program](quickstart/run_example_quickstart.html) working on live Wikipedia edits.
 
 - **Programming Guides**: You can check out our guides about [basic concepts](dev/api_concepts.html) and the [DataStream API](dev/datastream_api.html) or [DataSet API](dev/batch/index.html) to learn how to write your first Flink programs.
+
+## Migration Guide
+
+For users that have used prior versions of Apache Flink we recommend checking out the [API migration guide](dev/migration.html).
+While all parts of the API that were marked as public and stable are still supported (backwards compatible), we suggest to migrate applications to the
+newer interfaces where applicable.
+
+For users that look to upgrade an operation Flink system to the latest version, we recommend to check out the guide on [upgrading Apache Flink](ops/upgrading.html)
+

[04/10] flink git commit: [hotfix] [docs] Move section about internal snapshot implementation from 'state_backends.md' to 'stream_checkpointing.md'

Posted by se...@apache.org.

[hotfix] [docs] Move section about internal snapshot implementation from 'state_backends.md' to 'stream_checkpointing.md'


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

Branch: refs/heads/release-1.2
Commit: ac193d6a94ddb7e0fb0b86879ae25d979be11496
Parents: a562e3d
Author: Stephan Ewen <se...@apache.org>
Authored: Tue Jan 10 09:55:25 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:53:14 2017 +0100

----------------------------------------------------------------------
 docs/internals/state_backends.md       | 12 ------------
 docs/internals/stream_checkpointing.md | 14 +++++++++++++-
 2 files changed, 13 insertions(+), 13 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/ac193d6a/docs/internals/state_backends.md
----------------------------------------------------------------------
diff --git a/docs/internals/state_backends.md b/docs/internals/state_backends.md
index f6a4cc7..11d46ed 100644
--- a/docs/internals/state_backends.md
+++ b/docs/internals/state_backends.md
@@ -69,15 +69,3 @@ Examples are "ValueState", "ListState", etc. Flink's runtime encodes the states
 *Raw State* is state that users and operators keep in their own data structures. When checkpointed, they only write a sequence of bytes into
 the checkpoint. Flink knows nothing about the state's data structures and sees only the raw bytes.
 
-
-## Checkpointing Procedure
-
-When operator snapshots are taken, there are two parts: the **synchronous** and the **asynchronous** parts.
-
-Operators and state backends provide their snapshots as a Java `FutureTask`. That task contains the state where the *synchronous* part
-is completed and the *asynchronous* part is pending. The asynchronous part is then executed by a background thread for that checkpoint.
-
-Operators that checkpoint purely synchronously return an already completed `FutureTask`.
-If an asynchronous operation needs to be performed, it is executed in the `run()` method of that `FutureTask`.
-
-The tasks are cancelable, in order to release streams and other resource consuming handles.

http://git-wip-us.apache.org/repos/asf/flink/blob/ac193d6a/docs/internals/stream_checkpointing.md
----------------------------------------------------------------------
diff --git a/docs/internals/stream_checkpointing.md b/docs/internals/stream_checkpointing.md
index 75493ca..e8b3e46 100644
--- a/docs/internals/stream_checkpointing.md
+++ b/docs/internals/stream_checkpointing.md
@@ -138,7 +138,7 @@ in *at least once* mode.
 
 Note that the above described mechanism implies that operators stop processing input records while they are storing a snapshot of their state in the *state backend*. This *synchronous* state snapshot introduces a delay every time a snapshot is taken.
 
-It is possible to let an operator continue processing while it stores its state snapshot, effectively letting the state snapshots happen *asynchronously* in the background. To do that, the operator must be able to produce a state object that should be stored in a way such that further modifications to the operator state do not affect that state object.
+It is possible to let an operator continue processing while it stores its state snapshot, effectively letting the state snapshots happen *asynchronously* in the background. To do that, the operator must be able to produce a state object that should be stored in a way such that further modifications to the operator state do not affect that state object. An example for that are *copy-on-write* style data structures, such as used for example in RocksDB.
 
 After receiving the checkpoint barriers on its inputs, the operator starts the asynchronous snapshot copying of its state. It immediately emits the barrier to its outputs and continues with the regular stream processing. Once the background copy process has completed, it acknowledges the checkpoint to the checkpoint coordinator (the JobManager). The checkpoint is now only complete after all sinks received the barriers and all stateful operators acknowledged their completed backup (which may be later than the barriers reaching the sinks).
 
@@ -152,3 +152,15 @@ entire distributed dataflow, and gives each operator the state that was snapshot
 stream from position <i>S<sub>k</sub></i>. For example in Apache Kafka, that means telling the consumer to start fetching from offset <i>S<sub>k</sub></i>.
 
 If state was snapshotted incrementally, the operators start with the state of the latest full snapshot and then apply a series of incremental snapshot updates to that state.
+
+## Operator Snapshot Implementation
+
+When operator snapshots are taken, there are two parts: the **synchronous** and the **asynchronous** parts.
+
+Operators and state backends provide their snapshots as a Java `FutureTask`. That task contains the state where the *synchronous* part
+is completed and the *asynchronous* part is pending. The asynchronous part is then executed by a background thread for that checkpoint.
+
+Operators that checkpoint purely synchronously return an already completed `FutureTask`.
+If an asynchronous operation needs to be performed, it is executed in the `run()` method of that `FutureTask`.
+
+The tasks are cancelable, in order to release streams and other resource consuming handles.

[05/10] flink git commit: [FLINK-5456] [docs] Add stub for types of state and state interfaces

Posted by se...@apache.org.

[FLINK-5456] [docs] Add stub for types of state and state interfaces


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

Branch: refs/heads/release-1.2
Commit: 585095312a59fee953d6b370db0a939a8392dd19
Parents: ac193d6
Author: Stephan Ewen <se...@apache.org>
Authored: Tue Jan 10 12:31:21 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:53:24 2017 +0100

----------------------------------------------------------------------
 docs/dev/state.md                | 362 ----------------------------------
 docs/dev/stream/checkpointing.md | 152 ++++++++++++++
 docs/dev/stream/state.md         |  78 ++++++++
 docs/internals/state_backends.md |  71 -------
 4 files changed, 230 insertions(+), 433 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/58509531/docs/dev/state.md
----------------------------------------------------------------------
diff --git a/docs/dev/state.md b/docs/dev/state.md
deleted file mode 100644
index 4478bfc..0000000
--- a/docs/dev/state.md
+++ /dev/null
@@ -1,362 +0,0 @@
----
-title: "State & Checkpointing"
-nav-parent_id: streaming
-nav-id: state
-nav-pos: 40
----
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-All transformations in Flink may look like functions (in the functional processing terminology), but
-are in fact stateful operators. You can make *every* transformation (`map`, `filter`, etc) stateful
-by using Flink's state interface or checkpointing instance fields of your function. You can register
-any instance field
-as ***managed*** state by implementing an interface. In this case, and also in the case of using
-Flink's native state interface, Flink will automatically take consistent snapshots of your state
-periodically, and restore its value in the case of a failure.
-
-The end effect is that updates to any form of state are the same under failure-free execution and
-execution under failures.
-
-First, we look at how to make instance fields consistent under failures, and then we look at
-Flink's state interface.
-
-By default state checkpoints will be stored in-memory at the JobManager. For proper persistence of large
-state, Flink supports storing the checkpoints on file systems (HDFS, S3, or any mounted POSIX file system),
-which can be configured in the `flink-conf.yaml` or via `StreamExecutionEnvironment.setStateBackend(\u2026)`.
-See [state backends]({{ site.baseurl }}/ops/state_backends.html) for information
-about the available state backends and how to configure them.
-
-* ToC
-{:toc}
-
-Enabling Checkpointing
--------------------------
-
-Flink has a checkpointing mechanism that recovers streaming jobs after failures. The checkpointing mechanism requires a *persistent* (or *durable*) source that
-can be asked for prior records again (Apache Kafka is a good example of such a source).
-
-The checkpointing mechanism stores the progress in the data sources and data sinks, the state of windows, as well as the user-defined state (see [Working with State]({{ site.baseurl }}/dev/state.html)) consistently to provide *exactly once* processing semantics. Where the checkpoints are stored (e.g., JobManager memory, file system, database) depends on the configured [state backend]({{ site.baseurl }}/ops/state_backends.html).
-
-The [docs on streaming fault tolerance]({{ site.baseurl }}/internals/stream_checkpointing.html) describe in detail the technique behind Flink's streaming fault tolerance mechanism.
-
-By default, checkpointing is disabled. To enable checkpointing, call `enableCheckpointing(n)` on the `StreamExecutionEnvironment`, where *n* is the checkpoint interval in milliseconds.
-
-Other parameters for checkpointing include:
-
-- *exactly-once vs. at-least-once*: You can optionally pass a mode to the `enableCheckpointing(n)` method to choose between the two guarantee levels.
-  Exactly-once is preferrable for most applications. At-least-once may be relevant for certain super-low-latency (consistently few milliseconds) applications.
-
-- *number of concurrent checkpoints*: By default, the system will not trigger another checkpoint while one is still in progress. This ensures that the topology does not spend too much time on checkpoints and not make progress with processing the streams. It is possible to allow for multiple overlapping checkpoints, which is interesting for pipelines that have a certain processing delay (for example because the functions call external services that need some time to respond) but that still want to do very frequent checkpoints (100s of milliseconds) to re-process very little upon failures.
-
-- *checkpoint timeout*: The time after which a checkpoint-in-progress is aborted, if it did not complete by then.
-
-<div class="codetabs" markdown="1">
-<div data-lang="java" markdown="1">
-{% highlight java %}
-StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
-
-// start a checkpoint every 1000 ms
-env.enableCheckpointing(1000);
-
-// advanced options:
-
-// set mode to exactly-once (this is the default)
-env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
-
-// checkpoints have to complete within one minute, or are discarded
-env.getCheckpointConfig().setCheckpointTimeout(60000);
-
-// allow only one checkpoint to be in progress at the same time
-env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
-{% endhighlight %}
-</div>
-<div data-lang="scala" markdown="1">
-{% highlight scala %}
-val env = StreamExecutionEnvironment.getExecutionEnvironment()
-
-// start a checkpoint every 1000 ms
-env.enableCheckpointing(1000)
-
-// advanced options:
-
-// set mode to exactly-once (this is the default)
-env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)
-
-// checkpoints have to complete within one minute, or are discarded
-env.getCheckpointConfig.setCheckpointTimeout(60000)
-
-// allow only one checkpoint to be in progress at the same time
-env.getCheckpointConfig.setMaxConcurrentCheckpoints(1)
-{% endhighlight %}
-</div>
-</div>
-
-{% top %}
-
-## Using the Key/Value State Interface
-
-The Key/Value state interface provides access to different types of state that are all scoped to
-the key of the current input element. This means that this type of state can only be used
-on a `KeyedStream`, which can be created via `stream.keyBy(\u2026)`.
-
-Now, we will first look at the different types of state available and then we will see
-how they can be used in a program. The available state primitives are:
-
-* `ValueState<T>`: This keeps a value that can be updated and
-retrieved (scoped to key of the input element, mentioned above, so there will possibly be one value
-for each key that the operation sees). The value can be set using `update(T)` and retrieved using
-`T value()`.
-
-* `ListState<T>`: This keeps a list of elements. You can append elements and retrieve an `Iterable`
-over all currently stored elements. Elements are added using `add(T)`, the Iterable can
-be retrieved using `Iterable<T> get()`.
-
-* `ReducingState<T>`: This keeps a single value that represents the aggregation of all values
-added to the state. The interface is the same as for `ListState` but elements added using
-`add(T)` are reduced to an aggregate using a specified `ReduceFunction`.
-
-All types of state also have a method `clear()` that clears the state for the currently
-active key (i.e. the key of the input element).
-
-It is important to keep in mind that these state objects are only used for interfacing
-with state. The state is not necessarily stored inside but might reside on disk or somewhere else.
-The second thing to keep in mind is that the value you get from the state
-depends on the key of the input element. So the value you get in one invocation of your
-user function can differ from the value in another invocation if the keys involved are different.
-
-To get a state handle you have to create a `StateDescriptor`. This holds the name of the state
-(as we will later see you can create several states, and they have to have unique names so
-that you can reference them), the type of the values that the state holds, and possibly
-a user-specified function, such as a `ReduceFunction`. Depending on what type of state you
-want to retrieve, you create either a `ValueStateDescriptor`, a `ListStateDescriptor` or
-a `ReducingStateDescriptor`.
-
-State is accessed using the `RuntimeContext`, so it is only possible in *rich functions*.
-Please see [here]({{ site.baseurl }}/dev/api_concepts#rich-functions) for
-information about that, but we will also see an example shortly. The `RuntimeContext` that
-is available in a `RichFunction` has these methods for accessing state:
-
-* `ValueState<T> getState(ValueStateDescriptor<T>)`
-* `ReducingState<T> getReducingState(ReducingStateDescriptor<T>)`
-* `ListState<T> getListState(ListStateDescriptor<T>)`
-
-This is an example `FlatMapFunction` that shows how all of the parts fit together:
-
-{% highlight java %}
-public class CountWindowAverage extends RichFlatMapFunction<Tuple2<Long, Long>, Tuple2<Long, Long>> {
-
-    /**
-     * The ValueState handle. The first field is the count, the second field a running sum.
-     */
-    private transient ValueState<Tuple2<Long, Long>> sum;
-
-    @Override
-    public void flatMap(Tuple2<Long, Long> input, Collector<Tuple2<Long, Long>> out) throws Exception {
-
-        // access the state value
-        Tuple2<Long, Long> currentSum = sum.value();
-
-        // update the count
-        currentSum.f0 += 1;
-
-        // add the second field of the input value
-        currentSum.f1 += input.f1;
-
-        // update the state
-        sum.update(currentSum);
-
-        // if the count reaches 2, emit the average and clear the state
-        if (currentSum.f0 >= 2) {
-            out.collect(new Tuple2<>(input.f0, currentSum.f1 / currentSum.f0));
-            sum.clear();
-        }
-    }
-
-    @Override
-    public void open(Configuration config) {
-        ValueStateDescriptor<Tuple2<Long, Long>> descriptor =
-                new ValueStateDescriptor<>(
-                        "average", // the state name
-                        TypeInformation.of(new TypeHint<Tuple2<Long, Long>>() {}), // type information
-                        Tuple2.of(0L, 0L)); // default value of the state, if nothing was set
-        sum = getRuntimeContext().getState(descriptor);
-    }
-}
-
-// this can be used in a streaming program like this (assuming we have a StreamExecutionEnvironment env)
-env.fromElements(Tuple2.of(1L, 3L), Tuple2.of(1L, 5L), Tuple2.of(1L, 7L), Tuple2.of(1L, 4L), Tuple2.of(1L, 2L))
-        .keyBy(0)
-        .flatMap(new CountWindowAverage())
-        .print();
-
-// the printed output will be (1,4) and (1,5)
-{% endhighlight %}
-
-This example implements a poor man's counting window. We key the tuples by the first field
-(in the example all have the same key `1`). The function stores the count and a running sum in
-a `ValueState`. Once the count reaches 2 it will emit the average and clear the state so that
-we start over from `0`. Note that this would keep a different state value for each different input
-key if we had tuples with different values in the first field.
-
-### State in the Scala DataStream API
-
-In addition to the interface described above, the Scala API has shortcuts for stateful
-`map()` or `flatMap()` functions with a single `ValueState` on `KeyedStream`. The user function
-gets the current value of the `ValueState` in an `Option` and must return an updated value that
-will be used to update the state.
-
-{% highlight scala %}
-val stream: DataStream[(String, Int)] = ...
-
-val counts: DataStream[(String, Int)] = stream
-  .keyBy(_._1)
-  .mapWithState((in: (String, Int), count: Option[Int]) =>
-    count match {
-      case Some(c) => ( (in._1, c), Some(c + in._2) )
-      case None => ( (in._1, 0), Some(in._2) )
-    })
-{% endhighlight %}
-
-## Checkpointing Instance Fields
-
-Instance fields can be checkpointed by using the `Checkpointed` interface.
-
-When the user-defined function implements the `Checkpointed` interface, the `snapshotState(\u2026)` and `restoreState(\u2026)`
-methods will be executed to draw and restore function state.
-
-In addition to that, user functions can also implement the `CheckpointListener` interface to receive notifications on
-completed checkpoints via the `notifyCheckpointComplete(long checkpointId)` method.
-Note that there is no guarantee for the user function to receive a notification if a failure happens between
-checkpoint completion and notification. The notifications should hence be treated in a way that notifications from
-later checkpoints can subsume missing notifications.
-
-The above example for `ValueState` can be implemented using instance fields like this:
-
-{% highlight java %}
-
-public class CountWindowAverage
-        extends RichFlatMapFunction<Tuple2<Long, Long>, Tuple2<Long, Long>>
-        implements Checkpointed<Tuple2<Long, Long>> {
-
-    private Tuple2<Long, Long> sum = null;
-
-    @Override
-    public void flatMap(Tuple2<Long, Long> input, Collector<Tuple2<Long, Long>> out) throws Exception {
-
-        // update the count
-        sum.f0 += 1;
-
-        // add the second field of the input value
-        sum.f1 += input.f1;
-
-
-        // if the count reaches 2, emit the average and clear the state
-        if (sum.f0 >= 2) {
-            out.collect(new Tuple2<>(input.f0, sum.f1 / sum.f0));
-            sum = Tuple2.of(0L, 0L);
-        }
-    }
-
-    @Override
-    public void open(Configuration config) {
-        if (sum == null) {
-            // only recreate if null
-            // restoreState will be called before open()
-            // so this will already set the sum to the restored value
-            sum = Tuple2.of(0L, 0L);
-        }
-    }
-
-    // regularly persists state during normal operation
-    @Override
-    public Serializable snapshotState(long checkpointId, long checkpointTimestamp) {
-        return sum;
-    }
-
-    // restores state on recovery from failure
-    @Override
-    public void restoreState(Tuple2<Long, Long> state) {
-        sum = state;
-    }
-}
-{% endhighlight %}
-
-## Stateful Source Functions
-
-Stateful sources require a bit more care as opposed to other operators.
-In order to make the updates to the state and output collection atomic (required for exactly-once semantics
-on failure/recovery), the user is required to get a lock from the source's context.
-
-{% highlight java %}
-public static class CounterSource
-        extends RichParallelSourceFunction<Long>
-        implements Checkpointed<Long> {
-
-    /**  current offset for exactly once semantics */
-    private long offset;
-
-    /** flag for job cancellation */
-    private volatile boolean isRunning = true;
-
-    @Override
-    public void run(SourceContext<Long> ctx) {
-        final Object lock = ctx.getCheckpointLock();
-
-        while (isRunning) {
-            // output and state update are atomic
-            synchronized (lock) {
-                ctx.collect(offset);
-                offset += 1;
-            }
-        }
-    }
-
-    @Override
-    public void cancel() {
-        isRunning = false;
-    }
-
-    @Override
-    public Long snapshotState(long checkpointId, long checkpointTimestamp) {
-        return offset;
-
-    }
-
-    @Override
-	public void restoreState(Long state) {
-        offset = state;
-    }
-}
-{% endhighlight %}
-
-Some operators might need the information when a checkpoint is fully acknowledged by Flink to communicate that with the outside world. In this case see the `org.apache.flink.runtime.state.CheckpointListener` interface.
-
-## State Checkpoints in Iterative Jobs
-
-Flink currently only provides processing guarantees for jobs without iterations. Enabling checkpointing on an iterative job causes an exception. In order to force checkpointing on an iterative program the user needs to set a special flag when enabling checkpointing: `env.enableCheckpointing(interval, force = true)`.
-
-Please note that records in flight in the loop edges (and the state changes associated with them) will be lost during failure.
-
-{% top %}
-
-## Restart Strategies
-
-Flink supports different restart strategies which control how the jobs are restarted in case of a failure. For more 
-information, see [Restart Strategies]({{ site.baseurl }}/dev/restart_strategies.html).

http://git-wip-us.apache.org/repos/asf/flink/blob/58509531/docs/dev/stream/checkpointing.md
----------------------------------------------------------------------
diff --git a/docs/dev/stream/checkpointing.md b/docs/dev/stream/checkpointing.md
new file mode 100644
index 0000000..774d9ef
--- /dev/null
+++ b/docs/dev/stream/checkpointing.md
@@ -0,0 +1,152 @@
+---
+title: "Checkpointing"
+nav-parent_id: streaming
+nav-pos: 50
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+* ToC
+{:toc}
+
+Every function and operator in Flink can be **stateful** (see [working with state](state.html) for details).
+Stateful functions store data across the processing of individual elements/events, making state a critical building block for
+any type of more elaborate operation.
+
+In order to make state fault tolerant, Flink needs to **checkpoint** the state. Checkpoints allow Flink to recover state and positions
+in the streams to give the application the same semantics as a failure-free execution.
+
+The [documentation on streaming fault tolerance](../../internals/stream_checkpointing.html) describe in detail the technique behind Flink's streaming fault tolerance mechanism.
+
+
+## Prerequisites
+
+Flink's checkpointing mechanism interacts with durable storage for streams and state. In general, it requires:
+
+  - A *persistent* (or *durable*) data source that can replay records for a certain amount of time. Examples for such sources are persistent messages queues (e.g., Apache Kafka, RabbitMQ, Amazon Kinesis, Google PubSub) or file systems (e.g., HDFS, S3, GFS, NFS, Ceph, ...).
+  - A persistent storage for state, typically a distributed filesystem (e.g., HDFS, S3, GFS, NFS, Ceph, ...)
+
+
+## Enabling and Configuring Checkpointing
+
+By default, checkpointing is disabled. To enable checkpointing, call `enableCheckpointing(n)` on the `StreamExecutionEnvironment`, where *n* is the checkpoint interval in milliseconds.
+
+Other parameters for checkpointing include:
+
+  - *exactly-once vs. at-least-once*: You can optionally pass a mode to the `enableCheckpointing(n)` method to choose between the two guarantee levels.
+    Exactly-once is preferrable for most applications. At-least-once may be relevant for certain super-low-latency (consistently few milliseconds) applications.
+
+  - *checkpoint timeout*: The time after which a checkpoint-in-progress is aborted, if it did not complete by then.
+
+  - *minimum time between checkpoints*: To make sure that the streaming application makes a certain amount of progress between checkpoints,
+    one can define how much time needs to pass between checkpoints. If this value is set for example to *5000*, the next checkpoint will be
+    started no sooner than 5 seconds after the previous checkpoint completed, regardless of the checkpoint duration and the checkpoint interval.
+    Note that this implies that the checkpoint interval will never be smaller than this parameter.
+    
+    It is often easier to configure applications by defining the "time between checkpoints" then the checkpoint interval, because the "time between checkpoints"
+    is not susceptible to the fact that checkpoints may sometimes take longer than on average (for example if the target storage system is temporarily slow).
+
+    Note that this value also implies that the number of concurrent checkpoints is *one*.
+
+  - *number of concurrent checkpoints*: By default, the system will not trigger another checkpoint while one is still in progress.
+    This ensures that the topology does not spend too much time on checkpoints and not make progress with processing the streams.
+    It is possible to allow for multiple overlapping checkpoints, which is interesting for pipelines that have a certain processing delay
+    (for example because the functions call external services that need some time to respond) but that still want to do very frequent checkpoints
+    (100s of milliseconds) to re-process very little upon failures.
+
+    This option cannot be used when a minimum time between checkpoints is defined.
+
+<div class="codetabs" markdown="1">
+<div data-lang="java" markdown="1">
+{% highlight java %}
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+
+// start a checkpoint every 1000 ms
+env.enableCheckpointing(1000);
+
+// advanced options:
+
+// set mode to exactly-once (this is the default)
+env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
+
+// make sure 500 ms of progress happen between checkpoints
+env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500);
+
+// checkpoints have to complete within one minute, or are discarded
+env.getCheckpointConfig().setCheckpointTimeout(60000);
+
+// allow only one checkpoint to be in progress at the same time
+env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
+{% endhighlight %}
+</div>
+<div data-lang="scala" markdown="1">
+{% highlight scala %}
+val env = StreamExecutionEnvironment.getExecutionEnvironment()
+
+// start a checkpoint every 1000 ms
+env.enableCheckpointing(1000)
+
+// advanced options:
+
+// set mode to exactly-once (this is the default)
+env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)
+
+// make sure 500 ms of progress happen between checkpoints
+env.getCheckpointConfig.setMinPauseBetweenCheckpoints(500)
+
+// checkpoints have to complete within one minute, or are discarded
+env.getCheckpointConfig.setCheckpointTimeout(60000)
+
+// allow only one checkpoint to be in progress at the same time
+env.getCheckpointConfig.setMaxConcurrentCheckpoints(1)
+{% endhighlight %}
+</div>
+</div>
+
+{% top %}
+
+
+## Selecting a State Backend
+
+The checkpointing mechanism stores the progress in the data sources and data sinks, the state of windows, as well as the [user-defined state](state.html) consistently to
+provide *exactly once* processing semantics. Where the checkpoints are stored (e.g., JobManager memory, file system, database) depends on the configured
+**State Backend**. 
+
+By default state will be kept in memory, and checkpoints will be stored in-memory at the master node (the JobManager). For proper persistence of large state,
+Flink supports various forms of storing and checkpointing state in so called **State Backends**, which can be set via `StreamExecutionEnvironment.setStateBackend(\u2026)`.
+
+See [state backends](../../ops/state_backends.html) for more details on the available state backends and options for job-wide and cluster-wide configuration.
+
+
+## State Checkpoints in Iterative Jobs
+
+Flink currently only provides processing guarantees for jobs without iterations. Enabling checkpointing on an iterative job causes an exception. In order to force checkpointing on an iterative program the user needs to set a special flag when enabling checkpointing: `env.enableCheckpointing(interval, force = true)`.
+
+Please note that records in flight in the loop edges (and the state changes associated with them) will be lost during failure.
+
+{% top %}
+
+
+## Restart Strategies
+
+Flink supports different restart strategies which control how the jobs are restarted in case of a failure. For more 
+information, see [Restart Strategies]({{ site.baseurl }}/dev/restart_strategies.html).
+
+{% top %}
+

http://git-wip-us.apache.org/repos/asf/flink/blob/58509531/docs/dev/stream/state.md
----------------------------------------------------------------------
diff --git a/docs/dev/stream/state.md b/docs/dev/stream/state.md
new file mode 100644
index 0000000..0b38a62
--- /dev/null
+++ b/docs/dev/stream/state.md
@@ -0,0 +1,78 @@
+---
+title: "Working with State"
+nav-parent_id: streaming
+nav-pos: 40
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+* ToC
+{:toc}
+
+Stateful functions and operators store data across the processing of individual elements/events, making state a critical building block for
+any type of more elaborate operation. For example: 
+
+  - When an application searches for certain event patterns, the state will store the sequence of events encountered so far.
+  - When aggregating events per minute, the state holds the pending aggregates.
+  - When training a machine learning model over a stream of data points, the state holds the current verstion of the model parameters.
+
+In order to make state fault tolerant, Flink needs to be aware of the state and [checkpoint](checkpointing.html) it.
+In many cases, Flink can also *manage* the state for the application, meaning Flink deals with the memory management (possibly spilling to disk
+if necessary) to allow applications to hold very large state.
+
+This document explains how to use Flink's state abstractions when developing an application.
+
+
+## Keyed State and Operator state
+
+There are two basic state backends: `Keyed State` and `Operator State`.
+
+#### Keyed State
+
+*Keyed State* is always relative to keys and can only be used in functions and operators on a `KeyedStream`.
+Examples of keyed state are the `ValueState` or `ListState` that one can create in a function on a `KeyedStream`, as
+well as the state of a keyed window operator.
+
+Keyed State is organized in so called *Key Groups*. Key Groups are the unit by which keyed state can be redistributed and
+there are as many key groups as the defined maximum parallelism.
+During execution each parallel instance of an operator gets one or more key groups.
+
+#### Operator State
+
+*Operator State* is state per parallel subtask. It subsumes the `Checkpointed` interface in Flink 1.0 and Flink 1.1.
+The new `CheckpointedFunction` interface is basically a shortcut (syntactic sugar) for the Operator State.
+
+Operator State needs special re-distribution schemes when parallelism is changed. There can be different variations of such
+schemes; the following are currently defined:
+
+  - **List-style redistribution:** Each operator returns a List of state elements. The whole state is logically a concatenation of
+    all lists. On restore/redistribution, the list is evenly divided into as many sublists as there are parallel operators.
+    Each operator gets a sublist, which can be empty, or contain one or more elements.
+
+
+## Raw and Managed State
+
+*Keyed State* and *Operator State* exist in two forms: *managed* and *raw*.
+
+*Managed State* is represented in data structures controlled by the Flink runtime, such as internal hash tables, or RocksDB.
+Examples are "ValueState", "ListState", etc. Flink's runtime encodes the states and writes them into the checkpoints.
+
+*Raw State* is state that users and operators keep in their own data structures. When checkpointed, they only write a sequence of bytes into
+the checkpoint. Flink knows nothing about the state's data structures and sees only the raw bytes.
+

http://git-wip-us.apache.org/repos/asf/flink/blob/58509531/docs/internals/state_backends.md
----------------------------------------------------------------------
diff --git a/docs/internals/state_backends.md b/docs/internals/state_backends.md
deleted file mode 100644
index 11d46ed..0000000
--- a/docs/internals/state_backends.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title:  "State and State Backends"
-nav-title: State Backends
-nav-parent_id: internals
-nav-pos: 4
----
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements.  See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership.  The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied.  See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-* This will be replaced by the TOC
-{:toc}
-
-**NOTE** This document is only a sketch of some bullet points, to be fleshed out.
-
-**NOTE** The structure of State Backends changed heavily between version 1.1 and 1.2. This documentation is only applicable
-to Apache Flink version 1.2 and later.
-
-
-## Keyed State and Operator state
-
-There are two basic state backends: `Keyed State` and `Operator State`.
-
-#### Keyed State
-
-*Keyed State* is always relative to keys and can only be used in functions and operators on a `KeyedStream`.
-Examples of keyed state are the `ValueState` or `ListState` that one can create in a function on a `KeyedStream`, as
-well as the state of a keyed window operator.
-
-Keyed State is organized in so called *Key Groups*. Key Groups are the unit by which keyed state can be redistributed and
-there are as many key groups as the defined maximum parallelism.
-During execution each parallel instance of an operator gets one or more key groups.
-
-#### Operator State
-
-*Operator State* is state per parallel subtask. It subsumes the `Checkpointed` interface in Flink 1.0 and Flink 1.1.
-The new `CheckpointedFunction` interface is basically a shortcut (syntactic sugar) for the Operator State.
-
-Operator State needs special re-distribution schemes when parallelism is changed. There can be different variations of such
-schemes; the following are currently defined:
-
-  - **List-style redistribution:** Each operator returns a List of state elements. The whole state is logically a concatenation of
-    all lists. On restore/redistribution, the list is evenly divided into as many sublists as there are parallel operators.
-    Each operator gets a sublist, which can be empty, or contain one or more elements.
-
-
-## Raw and Managed State
-
-*Keyed State* and *Operator State* exist in two forms: *managed* and *raw*.
-
-*Managed State* is represented in data structures controlled by the Flink runtime, such as internal hash tables, or RocksDB.
-Examples are "ValueState", "ListState", etc. Flink's runtime encodes the states and writes them into the checkpoints.
-
-*Raw State* is state that users and operators keep in their own data structures. When checkpointed, they only write a sequence of bytes into
-the checkpoint. Flink knows nothing about the state's data structures and sees only the raw bytes.
-

[03/10] flink git commit: [FLINK-5455] [docs] Add stub for Upgrading Jobs and Framework

Posted by se...@apache.org.

[FLINK-5455] [docs] Add stub for Upgrading Jobs and Framework


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

Branch: refs/heads/release-1.2
Commit: a562e3d973cb069f5060ee96af2491e745efcac0
Parents: 7aad751
Author: Stephan Ewen <se...@apache.org>
Authored: Mon Jan 9 20:48:35 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:53:04 2017 +0100

----------------------------------------------------------------------
 docs/ops/upgrading.md | 57 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/a562e3d9/docs/ops/upgrading.md
----------------------------------------------------------------------
diff --git a/docs/ops/upgrading.md b/docs/ops/upgrading.md
new file mode 100644
index 0000000..d94e884
--- /dev/null
+++ b/docs/ops/upgrading.md
@@ -0,0 +1,57 @@
+---
+title: "Upgrading Jobs and Flink Versions"
+nav-parent_id: setup
+nav-pos: 15
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+* ToC
+{:toc}
+
+## Upgrading Flink Streaming Applications
+
+  - Savepoint, stop/cancel, start from savepoint
+  - Atomic Savepoint and Stop (link to JIRA issue)
+
+  - Limitations: Breaking chaining behavior (link to Savepoint section)
+  - Encourage using `uid(...)` explicitly for every operator
+
+## Upgrading the Flink Framework Version
+
+  - Either "in place" : Savepoint -> stop/cancel -> shutdown cluster -> start new version -> start job 
+  - Another cluster variant : Savepoint -> resume in other cluster -> "flip switch" -> shutdown old cluster
+
+## Compatibility Table
+
+Savepoints are compatible across Flink versions as indicated by the table below:
+                             
+| Created with \ Resumed With | 1.1.x | 1.2.x |
+| ---------------------------:|:-----:|:-----:|
+| 1.1.x                       |   X   |   X   |
+| 1.2.x                       |       |   X   |
+
+
+
+## Special Considerations for Upgrades from Flink 1.1.x to Flink 1.2.x
+
+  - The parallelism of the Savepoint in Flink 1.1.x becomes the maximum parallelism in Flink 1.2.x.
+  - Increasing the parallelism for upgraded jobs is not possible out of the box.
+
+

[10/10] flink git commit: [FLINK-5457] [docs] Add documentation for asynchronous I/O

Posted by se...@apache.org.

[FLINK-5457] [docs] Add documentation for asynchronous I/O


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

Branch: refs/heads/release-1.2
Commit: f4869a66d10468b804908dfe2564154cedc9aaa6
Parents: b41d0ff
Author: Stephan Ewen <se...@apache.org>
Authored: Sun Jan 15 19:41:36 2017 +0100
Committer: Stephan Ewen <se...@apache.org>
Committed: Mon Jan 16 11:54:18 2017 +0100

----------------------------------------------------------------------
 .gitignore                 |   1 +
 docs/dev/stream/asyncio.md | 226 ++++++++++++++++++++++++++-
 docs/fig/async_io.svg      | 337 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 562 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/flink/blob/f4869a66/.gitignore
----------------------------------------------------------------------
diff --git a/.gitignore b/.gitignore
index 1b9c64e..9012d0a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -29,5 +29,6 @@ out/
 /docs/.rubydeps
 /docs/ruby2/.bundle
 /docs/ruby2/.rubydeps
+/docs/.jekyll-metadata
 *.ipr
 *.iws

http://git-wip-us.apache.org/repos/asf/flink/blob/f4869a66/docs/dev/stream/asyncio.md
----------------------------------------------------------------------
diff --git a/docs/dev/stream/asyncio.md b/docs/dev/stream/asyncio.md
index 2d0867a..abc0b24 100644
--- a/docs/dev/stream/asyncio.md
+++ b/docs/dev/stream/asyncio.md
@@ -1,5 +1,6 @@
 ---
-title: "Async I/O for External Data Access"
+title: "Asynchronous I/O for External Data Access"
+nav-title: "Async I/O"
 nav-parent_id: streaming
 nav-pos: 60
 ---
@@ -25,4 +26,225 @@ under the License.
 * ToC
 {:toc}
 
-**TDB**
+This page explains the use of Flink's API for asynchronous I/O with external data stores.
+For users not familiar with asynchronous or event-driven programming, an article about Futures and
+event-driven programming may be useful preparation.
+
+Note: Details about the design and implementation of the asynchronous I/O utility can be found in the proposal and design document
+[FLIP-12: Asynchronous I/O Design and Implementation](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65870673).
+
+
+## The need for Asynchronous I/O Operations
+
+When interacting with external systems (for example when enriching stream events with data stored in a database), one needs to take care
+that communication delay with the external system does not dominate the streaming application's total work.
+
+Naively accessing data in the external database, for example in a `MapFunction`, typically means **synchronous** interaction:
+A request is sent to the database and the `MapFunction` waits until the response has been received. In many cases, this waiting
+makes up the vast majority of the function's time.
+
+Asynchronous interaction with the database means that a single parallel function instance can handle many requests concurrently and
+receive the responses concurrently. That way, the waiting time can be overlayed with sending other requests and
+receiving responses. At the very least, the waiting time is amortized over multiple requests. This leads in most cased to much higher
+streaming throughput.
+
+<img src="../../fig/async_io.svg" class="center" width="50%" />
+
+*Note:* Improving throughput by just scaling the `MapFunction` to a very high parallelism is in some cases possible as well, but usually
+comes at a very high resource cost: Having many more parallel MapFunction instances means more tasks, threads, Flink-internal network
+connections, network connections to the database, buffers, and general internal bookkeeping overhead.
+
+
+## Prerequisites
+
+As illustrated in the section above, implementing proper asynchronous I/O to a database (or key/value store) requires a client
+to that database that supports asynchronous requests. Many popular databases offer such a client.
+
+In the absence of such a client, one can try and turn a synchronous client into a limited concurrent client by creating
+multiple clients and handling the synchronous calls with a thread pool. However, this approach is usually less
+efficient than a proper asynchronous client.
+
+
+## Async I/O API
+
+Flink's Async I/O API allows users to use asynchronous request clients with data streams. The API handles the integration with
+data streams, well as handling order, event time, fault tolerance, etc.
+
+Assuming one has an asynchronous client for the target database, three parts are needed to implement a stream transformation
+with asynchronous I/O against the database:
+
+  - An implementation of `AsyncFunction` that dispatches the requests
+  - A *callback* that takes the result of the operation and hands it to the `AsyncCollector`
+  - Applying the async I/O operation on a DataStream as a transformation
+
+The following code example illustrates the basic pattern:
+
+<div class="codetabs" markdown="1">
+<div data-lang="java" markdown="1">
+{% highlight java %}
+// This example implements the asynchronous request and callback with Futures that have the
+// interface of Java 8's futures (which is the same one followed by Flink's Future)
+
+/**
+ * An implementation of the 'AsyncFunction' that sends requests and sets the callback.
+ */
+class AsyncDatabaseRequest extends RichAsyncFunction<String, Tuple2<String, String>> {
+
+    /** The database specific client that can issue concurrent requests with callbacks */
+    private transient DatabaseClient client;
+
+    @Override
+    public void open(Configuration parameters) throws Exception {
+        client = new DatabaseClient(host, post, credentials);
+    }
+
+    @Override
+    public void close() throws Exception {
+        client.close();
+    }
+
+    @Override
+    public void asyncInvoke(final String str, final AsyncCollector<Tuple2<String, String>> asyncCollector) throws Exception {
+
+        // issue the asynchronous request, receive a future for result
+        Future<String> resultFuture = client.query(str);
+
+        // set the callback to be executed once the request by the client is complete
+        // the callback simply forwards the result to the collector
+        resultFuture.thenAccept( (String result) -> {
+
+            asyncCollector.collect(Collections.singleton(new Tuple2<>(str, result)));
+         
+        });
+    }
+}
+
+// create the original stream
+DataStream<String> stream = ...;
+
+// apply the async I/O transformation
+DataStream<Tuple2<String, String>> resultStream =
+    AsyncDataStream.unorderedWait(stream, new AsyncDatabaseRequest(), 1000, TimeUnit.MILLISECONDS, 100);
+
+{% endhighlight %}
+</div>
+<div data-lang="scala" markdown="1">
+{% highlight scala %}
+/**
+ * An implementation of the 'AsyncFunction' that sends requests and sets the callback.
+ */
+class AsyncDatabaseRequest extends AsyncFunction[String, (String, String)] {
+
+    /** The database specific client that can issue concurrent requests with callbacks */
+    lazy val client: DatabaseClient = new DatabaseClient(host, post, credentials)
+
+    /** The context used for the future callbacks */
+    implicit lazy val executor: ExecutionContext = ExecutionContext.fromExecutor(Executors.directExecutor()))
+
+
+    override def asyncInvoke(str: String, asyncCollector: AsyncCollector[(String, String)]): Unit = {
+
+        // issue the asynchronous request, receive a future for the result
+        val resultFuture: Future[String] = client.query(str)
+
+        // set the callback to be executed once the request by the client is complete
+        // the callback simply forwards the result to the collector
+        resultFuture.onSuccess {
+            case result: String => asyncCollector.collect(Collections.singleton((str, result)));
+        })
+    }
+}
+
+// create the original stream
+val stream: DataStream[String] = ...
+
+// apply the async I/O transformation
+val resultStream: DataStream[(String, String)] =
+    AsyncDataStream.unorderedWait(stream, new AsyncDatabaseRequest(), 1000, TimeUnit.MILLISECONDS, 100)
+
+{% endhighlight %}
+</div>
+</div>
+
+The following two parameters control the asynchronous operations:
+
+  - **Timeout**: The timeout defines how long an asynchronous request may take before it is considered failed. This parameter
+    guards against dead/failed requests.
+
+  - **Capacity**: This parameter defines how many asynchronous requests may be in progress at the same time.
+    Even though the async I/O approach leads typically to much better throughput, the operator can still be the bottleneck in
+    the streaming application. Limiting the number of concurrent requests ensures that the operator will not
+    accumulate an ever-growing backlog of pending requests, but that it will trigger backpressure once the capacity
+    is exhausted.
+
+
+### Order of Results
+
+The concurrent requests issued by the `AsyncFunction` frequently complete in some undefined order, based on which request finished first.
+To control in which order the resulting records are emitted, Flink offers two modes:
+
+  - **Unordered**: Result records are emitted as soon as the asynchronous request finishes.
+    The order of the records in the stream is different after the async I/O operator than before.
+    This mode has the lowest latency and lowest overhead, when used with *processing time* as the basic time characteristic.
+    Use `AsyncDataStream.unorderedWait(...)` for this mode.
+
+  - **Ordered**: In that case, the stream order is preserved. Result records are emitted in the same order as the asynchronous
+    requests are triggered (the order of the operators input records). To achieve that, the operator buffers a result record
+    until all its preceeding records are emitted (or timed out).
+    This usually introduces some amount of extra latency and some overhead in checkpointing, because records or results are maintained
+    in the checkpointed state for a longer time, compared to the unordered mode.
+    Use `AsyncDataStream.orderedWait(...)` for this mode.
+
+
+### Event Time
+
+When the streaming application works with [event time](../event_time.html), watermarks will be handled correctly by the
+asynchronous I/O operator. That means concretely the following for the two order modes:
+
+  - **Unordered**: Watermarks do not overtake records and vice versa, meaning watermarks establish an *order boundary*.
+    Records are emitted unordered only between watermarks.
+    A record occurring after a certain watermark will be emitted only after that watermark was emitted.
+    The watermark in turn will be emitted only after all result records from inputs before that watermark were emitted.
+
+    That means that in the presence of watermarks, the *unordered* mode introduces some of the same latency and management
+    overhead as the *ordered* mode does. The amount of that overhead depends on the watermark frequency.
+
+  - **Ordered**: Order of watermarks an records is preserved, just like order between records is preserved. There is no
+    significant change in overhead, compared to working with *processing time*.
+
+Please recall that *Ingestion Time* is a special case of *event time* with automatically generated watermarks that
+are based on the sources processing time.
+
+
+### Fault Tolerance Guarantees
+
+The asynchronous I/O operator offers full exactly-once fault tolerance guarantees. It stores the records for in-flight
+asynchronous requests in checkpoints and restores/re-triggers the requests when recovering from a failure.
+
+
+### Implementation Tips
+
+For implementations with *Futures* that have an *Executor* (or *ExecutionContext* in Scala) for callbacks, we suggets to use a `DirectExecutor`, because the
+callback typically does minimal work, and a `DirectExecutor` avoids an additional thread-to-thread handover overhead. The callback typically only hands
+the result to the `AsyncCollector`, which adds it to the output buffer. From there, the heavy logic that includes record emission and interaction
+with the checkpoint bookkeepting happens in a dedicated thread-pool anyways.
+
+A `DirectExecutor` can be obtained via `org.apache.flink.runtime.concurrent.Executors.directExecutor()` or
+`com.google.common.util.concurrent.MoreExecutors.directExecutor()`.
+
+
+### Caveat
+
+**The AsyncFunction is not called Multi-Threaded**
+
+A common confusion that we want to explicitly point out here is that the `AsyncFunction` is not called in a multi-threaded fashion.
+There exists only one instance of the `AsyncFunction` and it is called sequentially for each record in the respective partition
+of the stream. Unless the `asyncInvoke(...)` method returns fast and relies on a callback (by the client), it will not result in
+proper asynchronous I/O.
+
+For example, the following patterns result in a blocking `asyncInvoke(...)` functions and thus void the asynchronous behavior:
+
+  - Using a database client whose lookup/query method call blocks until the result has been received back
+
+  - Blocking/waiting on the future-type objects returned by an aynchronous client inside the `asyncInvoke(...)` method
+

http://git-wip-us.apache.org/repos/asf/flink/blob/f4869a66/docs/fig/async_io.svg
----------------------------------------------------------------------
diff --git a/docs/fig/async_io.svg b/docs/fig/async_io.svg
new file mode 100644
index 0000000..0dd5c5d
--- /dev/null
+++ b/docs/fig/async_io.svg
@@ -0,0 +1,337 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   version="1.1"
+   width="490.91293"
+   height="326.60162"
+   id="svg2">
+  <defs
+     id="defs4" />
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     transform="translate(-223.11497,-374.77565)"
+     id="layer1">
+    <g
+       transform="translate(186.29955,360.58613)"
+       id="g2989">
+      <path
+         d="m 287.49975,36.027725 0,5.007498 -1.24719,0 0,-5.007498 1.24719,0 z m 0,8.758432 0,4.998121 -1.24719,0 0,-4.998121 1.24719,0 z m 0,8.749055 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.749055 0,5.007497 -1.24719,0 0,-5.007497 1.24719,0 z m 0,8.758432 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.749054 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.749055 0,5.007497 -1.24719,0 0,-5.007497 1.24719,0 z m 0,8.758432 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74906 0,5.0075 -1.24719,0 0,-5.0075 1.24719,0 z m 0,8.75843 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74906 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,5.0075 -1.24719,0 0,-5.0075 1.24719,0 z m 0,8.75843 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74906 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,5.0075 -1.24719,0 0,-5.0075 1.24719,0 z m 0,8.75843 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74906 0,
 4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,5.0075 -1.24719,0 0,-5.0075 1.24719,0 z m 0,8.75843 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74906 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,5.0075 -1.24719,0 0,-5.0075 1.24719,0 z m 0,8.75844 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,5.0075 -1.24719,0 0,-5.0075 1.24719,0 z m 0,8.75844 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74906 0,5.00749 -1.24719,0 0,-5.00749 1.24719,0 z m 0,8.75843 0,4.99812 -1.24719,0 0,-4.99812 1.24719,0 z m 0,8.74905 0,4.36984 -1.24719,0 0,-4.36984 1.24719,0 z"
+         id="path2991"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.00937734px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 315.47234,50.731388 0,21.399082 20.16127,0 0,-21.399082 -20.16127,0 z"
+         id="path2993"
+         style="fill:#5b9bd5;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="321.22928"
+         y="67.309143"
+         id="text2995"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">a</text>
+      <path
+         d="m 315.47234,73.855899 0,21.249044 20.16127,0 0,-21.249044 -20.16127,0 z"
+         id="path2997"
+         style="fill:#5b9bd5;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="321.07925"
+         y="90.391762"
+         id="text2999"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">b</text>
+      <path
+         d="m 315.47234,96.830373 0,21.417837 20.16127,0 0,-21.417837 -20.16127,0 z"
+         id="path3001"
+         style="fill:#5b9bd5;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="321.82944"
+         y="113.47438"
+         id="text3003"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">c</text>
+      <path
+         d="m 315.47234,119.95488 0,21.41784 20.16127,0 0,-21.41784 -20.16127,0 z"
+         id="path3005"
+         style="fill:#5b9bd5;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="321.07925"
+         y="136.55701"
+         id="text3007"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">d</text>
+      <path
+         d="m 315.47234,189.81604 0,21.2678 20.16127,0 0,-21.2678 -20.16127,0 z"
+         id="path3009"
+         style="fill:#548235;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="321.07925"
+         y="206.38158"
+         id="text3011"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">b</text>
+      <path
+         d="m 315.47234,212.79051 0,21.41784 20.16127,0 0,-21.41784 -20.16127,0 z"
+         id="path3013"
+         style="fill:#548235;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="321.82944"
+         y="229.4642"
+         id="text3015"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">c</text>
+      <path
+         d="m 315.47234,235.93378 0,21.39908 20.16127,0 0,-21.39908 -20.16127,0 z"
+         id="path3017"
+         style="fill:#548235;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="321.07925"
+         y="252.54683"
+         id="text3019"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">d</text>
+      <path
+         d="m 48.855921,319.54211 0,21.24904 20.161273,0 0,-21.24904 -20.161273,0 z"
+         id="path3021"
+         style="fill:#5b9bd5;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="54.577576"
+         y="336.11618"
+         id="text3023"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">x</text>
+      <path
+         d="m 527.10006,152.40047 c 0,4.68866 -17.04799,8.51462 -38.05323,8.51462 -21.02398,0 -38.07198,-3.82596 -38.07198,-8.51462"
+         id="path3025"
+         style="fill:none;stroke:#000000;stroke-width:1.25656307px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 450.97485,152.40047 c 0,-4.70743 17.048,-8.53338 38.07198,-8.53338 21.00524,0 38.05323,3.82595 38.05323,8.53338 l 0,34.05848 c 0,4.70742 -17.04799,8.51462 -38.05323,8.51462 -21.02398,0 -38.07198,-3.8072 -38.07198,-8.51462 z"
+         id="path3027"
+         style="fill:none;stroke:#000000;stroke-width:1.25656307px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 36.815422,50.722011 0,21.408459 20.31131,0 0,-21.408459 -20.31131,0 z"
+         id="path3029"
+         style="fill:#5b9bd5;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="42.636166"
+         y="67.309143"
+         id="text3031"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">a</text>
+      <path
+         d="m 36.815422,73.855899 0,67.516821 20.31131,0 0,-67.516821 -20.31131,0 z"
+         id="path3033"
+         style="fill:#c55a11;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <path
+         d="m 36.815422,143.39822 0,21.25843 20.31131,0 0,-21.25843 -20.31131,0 z"
+         id="path3035"
+         style="fill:#548235;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="42.636166"
+         y="159.92798"
+         id="text3037"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">a</text>
+      <path
+         d="m 248.27435,152.39109 c 0,4.69804 -17.03862,8.51462 -38.06261,8.51462 -21.01461,0 -38.05323,-3.81658 -38.05323,-8.51462"
+         id="path3039"
+         style="fill:none;stroke:#000000;stroke-width:1.24718571px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 172.15851,152.39109 c 0,-4.70742 17.03862,-8.524 38.05323,-8.524 21.02399,0 38.06261,3.81658 38.06261,8.524 l 0,34.06786 c 0,4.70742 -17.03862,8.51462 -38.06261,8.51462 -21.01461,0 -38.05323,-3.8072 -38.05323,-8.51462 z"
+         id="path3041"
+         style="fill:none;stroke:#000000;stroke-width:1.24718571px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 36.815422,166.3727 0,21.41783 20.31131,0 0,-21.41783 -20.31131,0 z"
+         id="path3043"
+         style="fill:#5b9bd5;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="42.48613"
+         y="183.0106"
+         id="text3045"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">b</text>
+      <path
+         d="m 36.815422,189.50659 0,67.51682 20.31131,0 0,-67.51682 -20.31131,0 z"
+         id="path3047"
+         style="fill:#c55a11;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <path
+         d="m 36.815422,259.05829 0,21.24904 20.31131,0 0,-21.24904 -20.31131,0 z"
+         id="path3049"
+         style="fill:#548235;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="42.48613"
+         y="275.62946"
+         id="text3051"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">b</text>
+      <path
+         d="m 315.47234,166.3727 0,21.41783 20.16127,0 0,-21.41783 -20.16127,0 z"
+         id="path3053"
+         style="fill:#548235;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="321.22928"
+         y="183.01012"
+         id="text3055"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">a</text>
+      <path
+         d="M 335.98995,60.840157 449.64327,136.459 448.94934,137.50926 335.29603,61.871664 z m 110.05242,68.079463 4.29482,8.75843 -9.73367,-0.5814 c -0.35634,-0.0188 -0.61891,-0.31883 -0.60015,-0.65641 0.0187,-0.35634 0.31883,-0.6189 0.65641,-0.58139 l 8.68341,0.50637 -0.60015,0.90023 -3.82595,-7.80195 c -0.15004,-0.31883 -0.0187,-0.69392 0.28132,-0.84396 0.31883,-0.15004 0.69392,-0.0188 0.84396,0.30008 z"
+         id="path3057"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.01875467px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 162.30293,159.99611 -103.966522,-5.27944 0.06564,-1.24719 103.966532,5.27007 z m -97.008539,-0.62828 -8.167659,-5.33571 8.664658,-4.48236 c 0.309452,-0.15942 0.684546,-0.0375 0.843961,0.26256 0.159414,0.30945 0.03751,0.68455 -0.262566,0.84396 l -7.717548,3.99475 0.05627,-1.0784 7.267435,4.74494 c 0.290697,0.18754 0.375093,0.58139 0.178169,0.87209 -0.187546,0.28132 -0.572017,0.36571 -0.862715,0.17817 z"
+         id="path3059"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.00937734px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 57.154864,177.70052 105.992026,-3.3102 -0.0375,-1.25656 -106.001403,3.31957 z m 98.940276,1.2003 8.27081,-5.17629 -8.57089,-4.65116 c -0.30945,-0.16879 -0.68454,-0.0563 -0.85334,0.25319 -0.15941,0.30007 -0.0469,0.68454 0.25319,0.84396 l 7.63315,4.14478 -0.0281,-1.08777 -7.36121,4.61365 c -0.30007,0.17817 -0.38447,0.57202 -0.19692,0.86271 0.17817,0.2907 0.56264,0.3751 0.85334,0.19693 z"
+         id="path3061"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.00937734px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 163.98148,183.86143 -106.273353,84.52731 0.778318,0.97524 106.273355,-84.52731 z m -103.319493,76.69723 -3.535255,9.08664 9.658656,-1.39722 c 0.337584,-0.0469 0.581395,-0.36572 0.525131,-0.7033 -0.04689,-0.34696 -0.365716,-0.5814 -0.7033,-0.53451 l -8.599018,1.24718 0.675168,0.84396 3.141408,-8.09264 c 0.131283,-0.31883 -0.02813,-0.68454 -0.346961,-0.80645 -0.328207,-0.13128 -0.684546,0.0281 -0.815829,0.35634 z"
+         id="path3063"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.00937734px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <text
+         x="104.91452"
+         y="29.350618"
+         id="text3065"
+         xml:space="preserve"
+         style="font-size:19.95497131px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">Sync. I/O</text>
+      <text
+         x="387.67728"
+         y="29.350618"
+         id="text3067"
+         xml:space="preserve"
+         style="font-size:19.95497131px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">Async</text>
+      <text
+         x="446.49194"
+         y="29.350618"
+         id="text3069"
+         xml:space="preserve"
+         style="font-size:19.95497131px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">. I/O</text>
+      <path
+         d="m 335.93369,83.927158 110.5963,58.870912 -0.60015,1.08778 -110.57755,-58.852166 z m 106.26397,51.706632 5.13878,8.28956 -9.75243,0.3751 c -0.35634,0.0188 -0.63766,-0.24381 -0.65641,-0.60015 -0.0188,-0.33759 0.26257,-0.63766 0.60015,-0.63766 l 8.68341,-0.33758 -0.50637,0.93773 -4.57614,-7.37059 c -0.1688,-0.30007 -0.0938,-0.69392 0.2063,-0.86271 0.30007,-0.18755 0.67517,-0.0938 0.86271,0.2063 z"
+         id="path3071"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.01875467px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 335.87743,107.03291 110.54003,45.70514 -0.46886,1.14404 -110.54004,-45.68639 z m 105.53254,38.99097 5.92647,7.76443 -9.67741,1.31283 c -0.33758,0.0563 -0.65641,-0.18755 -0.69392,-0.52513 -0.0563,-0.33759 0.18755,-0.65641 0.52513,-0.71268 l 8.60839,-1.18154 -0.4126,1.01275 -5.27006,-6.92047 c -0.2063,-0.26257 -0.15004,-0.65642 0.13128,-0.88147 0.26257,-0.20631 0.65641,-0.15004 0.86272,0.13128 z"
+         id="path3073"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.01875467px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 335.80241,129.98863 108.51453,29.68865 -0.33758,1.2003 -108.49578,-29.68865 z m 102.70058,23.64965 6.84546,6.95798 -9.4336,2.51312 c -0.33759,0.0938 -0.67517,-0.0938 -0.76894,-0.43135 -0.0938,-0.33759 0.11252,-0.67517 0.45011,-0.76894 l 8.38334,-2.25057 -0.28132,1.05027 -6.07652,-6.2078 c -0.24381,-0.24381 -0.24381,-0.63766 0,-0.88147 0.24381,-0.24381 0.63766,-0.22506 0.88147,0.0188 z"
+         id="path3075"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.01875467px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 440.77231,172.01785 -103.91964,4.44486 0.0563,1.23781 103.91964,-4.44486 z m -96.92415,-0.15003 -8.21455,5.27006 8.62715,4.55738 c 0.31883,0.15004 0.69393,0.0375 0.86272,-0.26256 0.15004,-0.31883 0.0375,-0.69392 -0.26257,-0.84396 l -7.68941,-4.05101 0.0375,1.06902 7.31432,-4.68867 c 0.30007,-0.18755 0.37509,-0.5814 0.18755,-0.86272 -0.18755,-0.30007 -0.56264,-0.37509 -0.86272,-0.18754 z"
+         id="path3077"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.01875467px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 440.65978,175.76879 -103.95715,23.85594 0.28132,1.21906 103.95715,-23.85595 z m -97.89939,18.06075 -7.12678,6.67666 9.32108,2.90698 c 0.31883,0.11252 0.67517,-0.075 0.78769,-0.41261 0.0938,-0.31883 -0.0938,-0.67517 -0.4126,-0.78769 l -8.28956,-2.58815 0.24381,1.06902 6.32032,-5.94523 c 0.26257,-0.24381 0.26257,-0.63766 0.0375,-0.88147 -0.24381,-0.26257 -0.63766,-0.28132 -0.88147,-0.0375 z"
+         id="path3079"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.01875467px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 440.56601,180.34493 -104.01342,42.23552 0.46887,1.14404 104.01341,-42.23553 z m -98.96841,35.5401 -5.96399,7.72693 9.65866,1.38784 c 0.35634,0.0563 0.65641,-0.18754 0.71268,-0.52513 0.0563,-0.33758 -0.18755,-0.65641 -0.52513,-0.71268 l -8.6084,-1.21905 0.41261,0.994 5.30757,-6.88297 c 0.2063,-0.26256 0.15004,-0.65641 -0.11253,-0.88147 -0.28132,-0.2063 -0.67517,-0.15003 -0.88147,0.11253 z"
+         id="path3081"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.01875467px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 440.47223,183.19564 -104.08843,62.26551 0.63766,1.06902 104.10719,-62.26552 z m -100.13119,54.89492 -4.70743,8.53338 9.77119,-0.0938 c 0.33758,-0.0188 0.6189,-0.30008 0.60015,-0.63766 0,-0.33759 -0.28132,-0.61891 -0.61891,-0.61891 l -8.68341,0.0938 0.54389,0.93773 4.20104,-7.6144 c 0.1688,-0.30007 0.0563,-0.67516 -0.24381,-0.84396 -0.30007,-0.16879 -0.69392,-0.0563 -0.86271,0.24381 z"
+         id="path3083"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.01875467px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <path
+         d="m 57.529957,60.868289 106.273353,86.459041 -0.7877,0.97524 L 56.732884,61.834154 z m 103.403883,78.600831 3.43211,9.12415 -9.6399,-1.50038 c -0.33759,-0.0563 -0.57202,-0.37509 -0.51576,-0.71267 0.0469,-0.34696 0.36572,-0.57202 0.71268,-0.52513 l 8.58026,1.34096 -0.68454,0.83458 -3.05701,-8.12077 c -0.12191,-0.32821 0.0469,-0.68455 0.36571,-0.80646 0.32821,-0.1219 0.68455,0.0375 0.80645,0.36572 z"
+         id="path3085"
+         style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.00937734px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none" />
+      <text
+         x="178.40282"
+         y="180.86819"
+         id="text3087"
+         xml:space="preserve"
+         style="font-size:13.80343914px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">database</text>
+      <text
+         x="457.8309"
+         y="180.86819"
+         id="text3089"
+         xml:space="preserve"
+         style="font-size:13.80343914px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">database</text>
+      <path
+         d="m 315.47234,142.92936 0,21.2678 20.16127,0 0,-21.2678 -20.16127,0 z"
+         id="path3091"
+         style="fill:#c55a11;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="78.076439"
+         y="335.54126"
+         id="text3093"
+         xml:space="preserve"
+         style="font-size:13.80343914px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">sendRequest</text>
+      <text
+         x="166.74852"
+         y="335.54126"
+         id="text3095"
+         xml:space="preserve"
+         style="font-size:13.80343914px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">(x)</text>
+      <path
+         d="m 242.32912,319.54211 0,21.24904 20.16127,0 0,-21.24904 -20.16127,0 z"
+         id="path3097"
+         style="fill:#548235;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="248.05853"
+         y="336.11618"
+         id="text3099"
+         xml:space="preserve"
+         style="font-size:15.00373745px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">x</text>
+      <text
+         x="271.55743"
+         y="335.54126"
+         id="text3101"
+         xml:space="preserve"
+         style="font-size:13.80343914px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">receiveResponse</text>
+      <text
+         x="387.23621"
+         y="335.54126"
+         id="text3103"
+         xml:space="preserve"
+         style="font-size:13.80343914px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">(x)</text>
+      <path
+         d="m 457.23891,319.54211 0,21.24904 20.16127,0 0,-21.24904 -20.16127,0 z"
+         id="path3105"
+         style="fill:#c55a11;fill-opacity:1;fill-rule:evenodd;stroke:none" />
+      <text
+         x="486.51855"
+         y="335.54126"
+         id="text3107"
+         xml:space="preserve"
+         style="font-size:13.80343914px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Verdana">wait</text>
+    </g>
+  </g>
+</svg>