=doc #17358 remove duplicates

This commit is contained in:
Martynas Mickevičius 2015-06-02 15:05:12 +03:00
parent 0e6694a102
commit cfe4e697fa
4 changed files with 9 additions and 9 deletions

View file

@ -93,8 +93,8 @@ pipeline. In this example we use a :class:`Concat` graph processing stage to inj
continue with handling all incoming data using the echo handler. You should use this pattern of encapsulating complex
logic in Flows and attaching those to :class:`StreamIO` in order to implement your custom and possibly sophisticated TCP servers.
In this example both client and server may need to close the stream based on a parsed command command - ``BYE`` in the case
of the server, and ``q`` in the case of the client. This is implemented by using a custom :class:`PushStage`
In this example both client and server may need to close the stream based on a parsed command - ``BYE`` in the case
of the server, and ``q`` in the case of the client. This is implemented by using a custom :class:`PushStage`
(see :ref:`stream-using-push-pull-stage-scala`) which completes the stream once it encounters such command.
Streaming File IO

View file

@ -101,7 +101,7 @@ FlowGraphs are constructed like this:
As you can see, inside the :class:`FlowGraph` we use an implicit graph builder to mutably construct the graph
using the ``~>`` "edge operator" (also read as "connect" or "via" or "to"). Once we have the FlowGraph in the value ``g``
*it is immutable, thread-safe, and freely shareable*. A graph can can be ``run()`` directly - assuming all
*it is immutable, thread-safe, and freely shareable*. A graph can be ``run()`` directly - assuming all
ports (sinks/sources) within a flow have been connected properly. It is possible to construct partial graphs
where this is not required but this will be covered in detail in :ref:`partial-flow-graph-scala`.
@ -124,7 +124,7 @@ elements*" this can be expressed using the ``buffer`` element:
.. includecode:: code/docs/stream/TwitterStreamQuickstartDocSpec.scala#tweets-slow-consumption-dropHead
The ``buffer`` element takes an explicit and required ``OverflowStrategy``, which defines how the buffer should react
when it receives another element element while it is full. Strategies provided include dropping the oldest element (``dropHead``),
when it receives another element while it is full. Strategies provided include dropping the oldest element (``dropHead``),
dropping the entire buffer, signalling errors etc. Be sure to pick and choose the strategy that fits your use case best.
Materialized values