Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2677A200C1C for ; Wed, 15 Feb 2017 11:45:32 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 2521D160B70; Wed, 15 Feb 2017 10:45:32 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 4B8BB160B46 for ; Wed, 15 Feb 2017 11:45:31 +0100 (CET) Received: (qmail 12455 invoked by uid 500); 15 Feb 2017 10:45:30 -0000 Mailing-List: contact commits-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flink.apache.org Delivered-To: mailing list commits@flink.apache.org Received: (qmail 12443 invoked by uid 99); 15 Feb 2017 10:45:30 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2017 10:45:30 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 64611DFC31; Wed, 15 Feb 2017 10:45:30 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: uce@apache.org To: commits@flink.apache.org Message-Id: <9ba0cad8af364e72bee4663ea641562a@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: flink git commit: [FLINK-5796] [docs] Fix broken links Date: Wed, 15 Feb 2017 10:45:30 +0000 (UTC) archived-at: Wed, 15 Feb 2017 10:45:32 -0000 Repository: flink Updated Branches: refs/heads/release-1.2 bae4e89b6 -> 8368681e9 [FLINK-5796] [docs] Fix broken links This closes #3308. Project: http://git-wip-us.apache.org/repos/asf/flink/repo Commit: http://git-wip-us.apache.org/repos/asf/flink/commit/8368681e Tree: http://git-wip-us.apache.org/repos/asf/flink/tree/8368681e Diff: http://git-wip-us.apache.org/repos/asf/flink/diff/8368681e Branch: refs/heads/release-1.2 Commit: 8368681e9e3859de4871a3f1b0a0172c761032e8 Parents: bae4e89 Author: Nico Kruber Authored: Tue Feb 14 15:56:11 2017 +0100 Committer: Ufuk Celebi Committed: Wed Feb 15 11:44:22 2017 +0100 ---------------------------------------------------------------------- docs/dev/batch/index.md | 2 +- docs/dev/datastream_api.md | 2 +- docs/internals/stream_checkpointing.md | 4 ++-- docs/ops/state_backends.md | 2 +- docs/redirects/best_practices.md | 2 +- docs/redirects/fault_tolerance.md | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/flink/blob/8368681e/docs/dev/batch/index.md ---------------------------------------------------------------------- diff --git a/docs/dev/batch/index.md b/docs/dev/batch/index.md index 52807ca..d171a89 100644 --- a/docs/dev/batch/index.md +++ b/docs/dev/batch/index.md @@ -2135,7 +2135,7 @@ Passing Parameters to Functions Parameters can be passed to functions using either the constructor or the `withParameters(Configuration)` method. The parameters are serialized as part of the function object and shipped to all parallel task instances. -Check also the [best practices guide on how to pass command line arguments to functions]({{ site.baseurl }}/monitoring/best_practices.html#parsing-command-line-arguments-and-passing-them-around-in-your-flink-application). +Check also the [best practices guide on how to pass command line arguments to functions]({{ site.baseurl }}/dev/best_practices.html#parsing-command-line-arguments-and-passing-them-around-in-your-flink-application). #### Via Constructor http://git-wip-us.apache.org/repos/asf/flink/blob/8368681e/docs/dev/datastream_api.md ---------------------------------------------------------------------- diff --git a/docs/dev/datastream_api.md b/docs/dev/datastream_api.md index d02b850..f9f060b 100644 --- a/docs/dev/datastream_api.md +++ b/docs/dev/datastream_api.md @@ -1595,7 +1595,7 @@ for an explanation of most parameters. These parameters pertain specifically to ### Fault Tolerance -[State & Checkpointing]({{ site.baseurl }}/dev/state#enabling-checkpointing) describes how to enable and configure Flink's checkpointing mechanism. +[State & Checkpointing]({{ site.baseurl }}/dev/stream/checkpointing) describes how to enable and configure Flink's checkpointing mechanism. ### Controlling Latency http://git-wip-us.apache.org/repos/asf/flink/blob/8368681e/docs/internals/stream_checkpointing.md ---------------------------------------------------------------------- diff --git a/docs/internals/stream_checkpointing.md b/docs/internals/stream_checkpointing.md index e8b3e46..edc7967 100644 --- a/docs/internals/stream_checkpointing.md +++ b/docs/internals/stream_checkpointing.md @@ -103,7 +103,7 @@ the barrier *n* from the other inputs as well. Otherwise, it would have mixed re When operators contain any form of *state*, this state must be part of the snapshots as well. Operator state comes in different forms: - - *User-defined state*: This is state that is created and modified directly by the transformation functions (like `map()` or `filter()`). User-defined state can either be a simple variable in the function's java object, or the associated key/value state of a function (see [State in Streaming Applications]({{ site.baseurl }}/dev/state.html) for details). + - *User-defined state*: This is state that is created and modified directly by the transformation functions (like `map()` or `filter()`). User-defined state can either be a simple variable in the function's java object, or the associated key/value state of a function (see [State in Streaming Applications]({{ site.baseurl }}/dev/stream/state.html) for details). - *System state*: This state refers to data buffers that are part of the operator's computation. A typical example for this state are the *window buffers*, inside which the system collects (and aggregates) records for windows until the window is evaluated and evicted. Operators snapshot their state at the point in time when they received all snapshot barriers from their input streams, before emitting the barriers to their output streams. At that point, all updates to the state from records before the barriers will have been made, and no updates that depend on records from after the barriers have been applied. Because the state of a snapshot may be potentially large, it is stored in a configurable *state backend*. By default, this is the JobManager's memory, but for serious setups, a distributed reliable storage should be configured (such as HDFS). After the state has been stored, the operator acknowledges the checkpoint, emits the snapshot barrier into the output streams, and proceeds. @@ -142,7 +142,7 @@ It is possible to let an operator continue processing while it stores its state 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). -See [State Backends]({{ site.baseurl }}/internals/state_backends.html) for details on the state snapshots. +See [State Backends]({{ site.baseurl }}/ops/state_backends.html) for details on the state snapshots. ## Recovery http://git-wip-us.apache.org/repos/asf/flink/blob/8368681e/docs/ops/state_backends.md ---------------------------------------------------------------------- diff --git a/docs/ops/state_backends.md b/docs/ops/state_backends.md index af9934d..656594d 100644 --- a/docs/ops/state_backends.md +++ b/docs/ops/state_backends.md @@ -28,7 +28,7 @@ Programs written in the [Data Stream API]({{ site.baseurl }}/dev/datastream_api. - 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. +See also [Working with State]({{ site.baseurl }}/dev/stream/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 http://git-wip-us.apache.org/repos/asf/flink/blob/8368681e/docs/redirects/best_practices.md ---------------------------------------------------------------------- diff --git a/docs/redirects/best_practices.md b/docs/redirects/best_practices.md index 3d7d182..754477e 100644 --- a/docs/redirects/best_practices.md +++ b/docs/redirects/best_practices.md @@ -1,7 +1,7 @@ --- title: "Best Practices" layout: redirect -redirect: /monitoring/best_practices.html +redirect: /dev/best_practices.html permalink: /apis/best_practices.html ---