Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for multiple sinks per pipeline #2060

Merged
merged 12 commits into from
Feb 22, 2018
Merged

Add support for multiple sinks per pipeline #2060

merged 12 commits into from
Feb 22, 2018

Conversation

jtfmumm
Copy link
Contributor

@jtfmumm jtfmumm commented Feb 13, 2018

Closes #2060

@jtfmumm jtfmumm changed the title Multi sink WIP - Multi sink Feb 13, 2018
@jtfmumm jtfmumm force-pushed the multi-sink branch 2 times, most recently from e9af2f2 to f42e09e Compare February 14, 2018 14:12
@nisanharamati
Copy link
Contributor

@jtfmumm integration tests are added and enabled for the two apps:

  • testing/correctness/apps/multi_pipeline: two disjoint pipelines, each with their own source and sink
  • testing/correctness/apps/multi_sink: a single pipeline with one source and a two sinks (with duplicated output)

jtfmumm and others added 11 commits February 22, 2018 14:12
This adds to_sinks() to the Pony API and updates
the way we store information about sinks in the
Pipeline object to allow one or more sinks per
pipeline.
Prior to this commit, Wallaroo only supported one
routing target per output message from a Step. This
adds support in our routers for routing messages to
more than one routing target per message (duplicating
the same message, i.e. fan out).
Prior to this, creation of LocalTopology objects assumed
that there would be at most one sink per pipeline. This
updates the init algorithm prior to distribution of
LocalTopology workers across the cluster to support the
new to_sinks() API call which can specify more than one
sink per pipeline.
Prior to this commit, the algorithm for transforming
a LocalTopology graph into a collection of initiated
step actors assumed that there would only be one output
per node in the graph (unless we were dealing with a
partition). This removes that assumption from the
algorithm and supports multiple outputs per node.
- rename old `multi_sink` test app to `multi_pipeline`
- create new multi_sink test app that is one-pipeline-to-two-sinks
to_sinks() was creating multiple pipeline objects
when there should only have been one.
This change allows the application developer to add a multisink to a
Go application.

The Pony side is not yet implemented.
@jtfmumm jtfmumm changed the title WIP - Multi sink Add support for multiple sinks per pipeline Feb 22, 2018
@@ -51,10 +51,13 @@ func ApplicationSetup() *C.char {
application.NewPipeline("Split and Count", app.MakeTCPSourceConfig(inHost, inPort, &Decoder{})).
ToMulti(&SplitBuilder{}).
ToStatePartition(&CountWord{}, &WordTotalsBuilder{}, "word totals", &WordPartitionFunction{}, LetterPartition()).
ToSink(app.MakeTCPSinkConfig(outHost, outPort, &Encoder{}))
// ToSink(app.MakeTCPSinkConfig(outHost, outPort, &Encoder{}))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Get rid of this line.

This commit adds the Pony side of support for
to_sinks functionality with the Go API, completing
the Go API support for multiple sinks per pipeline.
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants