These are chat archives for akkadotnet/AkkaStreams

10th
Nov 2017
Boris Kreminski
@krembf
Nov 10 2017 20:22
Any help with my question above? Basically, I'm trying to see whether there is a room for improvement (assuming it makes any sense conceptually) by overloading the Sink.IActorRef method, in such way it can accept the reference to the actor to which the onCompleteMessage will be sent to:
public static Sink<TIn, NotUsed> ActorRef<TIn>(IActorRef actorRef, object onCompleteMessage, IActorRef receiverActorRef)
    => new Sink<TIn, NotUsed>(new ActorRefSink<TIn>(actorRef, onCompleteMessage, receiverActorRef, DefaultAttributes.ActorRefSink, Shape<TIn>("ActorRefSink")));
Bartosz Sypytkowski
@Horusiath
Nov 10 2017 22:08
@bobanco reactive streams are not request/response thing. Upstream is not waiting nor acking an individual messages it pushes. You can however intercept errors in the downstream and make appropriate reaction there. Regarding QueueOfferResult.Failure - it's opt in and used only if your overflow strategy is Fail.
@krembf this is pretty narrow use case. You can create a behavior in your actor which will forward completion message, when it'll come from stream
Boris Kreminski
@krembf
Nov 10 2017 22:44
@Horusiath Thanks so much for response! Sure, I can do that, but then my receive actor will have to process the data chunks, like you suggested, via Receive<ByteString>. Then I'm not sure how the flow control is going to work in this case. I assumed that if I create those special stream actors (one from source at sender's side and one from source at receiver side), they will interact with each other and the magic will handle the flow control events during data exchange. Then the completion messages will be sent to parent ReceiveActor. Something like in the scheme below (again, I'm might be misinterpreting things :)):
ReceiveActor SenderActor
-> ActorFromSource <-Exchange data with flow control-> <- ActorFromSource
Bartosz Sypytkowski
@Horusiath
Nov 10 2017 22:48
@krembf this may not work:
  1. By default ActorRef doesn't provide flow control in terms of backpressure. There are dedicated actors for that: ActorPublisher and ActorSubscriber
  2. More important, actor communication is at-most-once delivery, which means that in some cases messages send remotelly between actors may be lost. This is dangerous, as if you'll loose messges you may end up with deadlock in your reactive stream pipeline