Hi Ryan,

there are two ways to view this question:

   - if you just want to have the same result as merging before the router
   then whatever element replaces the “balance” will need to somehow know how
   the router decides for the corresponding sibling data element—this is
   impossible and merging before the router is the obvious and correct thing
   to do
   - if you are looking for a way to attach contextual data that travels
   with each element then that is currently not possible; we are exploring
   possibilities (mostly at the thought experiment level at this point) and
   the precise semantics of such a feature are very difficult to specify given
   the ability to conflate/expand/mapConcat and especially in the face of
   custom Stages

It is possible to lift a function into a different domain, e.g. from “pure
data” to “pure data with context”, and this can be done for .map() stages
(and those that are simple 1:1 stages like it), but in general
compositionality is not implemented in Akka Streams on that level. The
other reason besides the mentioned difficulty in specifying the semantics
is that we opted for mutability and side-effects in the implementation of
Stage in order to achieve good performance; the allocation overhead would
otherwise just kill us.

So, in summary, you’ll have to ferry those data through the flow—and its
types—yourself, as you have done by zipping before the router.

Regards,

Roland

On Wed, Aug 5, 2015 at 7:47 PM, Ryan Bair <[email protected]> wrote:

> I'm attempting to implement a flow graph like so:
>
>
> unzip.out0 ~> someLogic ~> router.in
>                            router.out1[C] ~> zipA.in0
>                            router.out2[D] ~> zipB.in0
> unzip.out1 ~> balance
>               balance ~>                  ~> zipA.in1
>               balance ~>                  ~> zipB.in1
>
>
> The shape of the graph is inlet (A, B) from unzip.in and two outlets of
> (C, B) and (D, B) from zipA and zipB. The idea is that the logic in
> `someLogic` really doesn't need to know about B so rather than piping it
> through, we'll just merge it back at the end. Keeping the pairs from the
> original input tuple together is important. `router`'s behavior is to send
> only to one output depending on the input data.
>
> The problem is that balance will send to one of the zips to fill its
> initial buffer and not necessarily the one that received data from
> `router`.
>
> I worked around the issue by zipping before `router` but that makes
> `router` slightly more complex.
>
> Is there a way to implement something like this with Akka Streams?
>
> Thanks
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Akka Team
Typesafe - Reactive apps on the JVM
Blog: letitcrash.com
Twitter: @akkateam

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to