2

I am trying to implement both the Source as origin and the Sink as remote, and then the Sink as origin and the Source as remote, Type 1 and Type 2 workflows within the AkkaStreamsModel Respectively.

Type 1 creates a SourceRef and passes this to the remote actor as an exposed source of incoming data to the sink actor. Type 2 creates a SinkRef and passes this to the remote actor as an exposed sink to start sending data to. For further explanation, I have uploaded both Type 1 (AkkaStreams) and Type 2 (AkkaStreamsFaulty) workflows onto GitHub.

The Type 1 workflow was set up and works correctly, however, the Type 2 workflow is faulty. I have narrowed the problem down to the Receive<PrepareUpload>() method within the DataReceiver actor. Upon succesful creation of the sink, the flow and the sink are sent (via a MeasurementsSinkReady message) to the source actor using the PipeTo() method.

Can anyone indicate where I may be going wrong within the Type 2 workflow? I have exhausted all other options (Akka.Net Documentation; Akka.Net Gitter, various blogs and videos etc). I am unsure of where to go from here, any help would be much appreciated.

Thank you.

Edit (Added extra information as per Bartosz Sypytkowski's comment)

The data is never sent between the two actors remotely, that is the problem. Using Type 1, a SourceRef is established and sent to the remote actor. The remote actor receives this message. However, for Type 2, the SinkRef is created but never reaches the remote actor. Therefore, I assume the problem is with the generation of the SinkRef or the PipeTo() method. This is because if you send a message between the actors it works, but if the message is conditional on the SinkRef being setup correctly, then something went wrong in the setup.

Brett
  • 43
  • 6
  • You didn't tell what issues did you encounter. – Bartosz Sypytkowski May 05 '20 at 06:26
  • The data is never sent between the two actors remotely, that is the problem. Using Type 1, a `SourceRef` is established and sent to the remote actor. The remote actor receives this message. However, for Type 2, the `SinkRef` is created but never reaches the remote actor. Therefore, I assume the problem is with the generation of the `SinkRef` or the `PipeTo()` method. This is because if you send a message between the actors it works, but if the message is conditional on the `SinkRef` being setup correctly, then something went wrong in the setup. – Brett May 05 '20 at 07:13
  • Does anyone have any ideas? I am out of ideas and could really use some help. – Brett May 14 '20 at 05:24
  • Do you have any code gist/snippet you can share that we can use to reproduce your problem? – Greg May 14 '20 at 16:23
  • Hi @Greg, please see the GitHub pages above that contain the problems, [AkkaStreamsFaulty](https://github.com/BrettGFleischer/AkkaStreamsFaulty). As discussed above, the problem has been narrowed down to the `Receive()` method within the `DataReceiver` actor. – Brett May 15 '20 at 05:23
  • I did a pull request on your [GitHub repo](https://github.com/BrettGFleischer/AkkaStreamsFaulty/pull/1) on how to fix it. – Greg May 15 '20 at 20:27
  • Hi @Greg I've made comments on your pull request as to why it was not a solution. Thanks for the effort though. – Brett May 18 '20 at 05:21
  • In a stream, for every sink, you will need a source. What your original code missing is a `Souce` for the sink to source from, so the problem was not in `PipeTo`. – Greg May 18 '20 at 13:42
  • I understand that a `Sink` needs a `Source`, the `Source` is in the remote actor system. Hence the title `Akka.Net: Reactive Streams over the network`. Once the `Sink` has been set up correctly, the `SinkRef` is sent to the `DataSource` actor (like so [SinkRef over the network](https://getakka.net/images/sink-ref-animation.gif)) and then the remote `Source` actor can send info to the `Sink`. – Brett May 19 '20 at 05:27
  • It turns out that, with the current serializer implementation, this can't really be done. The problem is that `NewtonsoftJsonSerializer` could not handle `SinkRef` serialization. If you want to do this, you'd have to send a naked `SinkRef`. So, as a fix, instead of sending the `ISinkRef` inside the `MeasurementsSinkReady` class, try sending an `ISinkRef`. This feature will be added as part of the 1.5.0 roadmap. – Greg May 22 '20 at 00:29
  • Great @Greg, May I get a link to this? For tracking purposes. – Brett May 22 '20 at 08:43
  • It is currently logged as this: https://github.com/akkadotnet/akka.net/pull/4425 – Greg Jun 02 '20 at 10:42
  • Hi @Greg, just wanted to know how and when to follow up on the issue? – Brett Jul 10 '20 at 09:07
  • Hi @Greg, what other avenues might I take to get the issue bumped by the Akka.Net team? – Brett Nov 05 '20 at 12:26
  • Hi @Brett, we're putting this issue into the next Akka.NET sprint, which will happen 2 weeks from now. – Greg Nov 06 '20 at 20:43

1 Answers1

1

This was a bug in the Akka.Streams implementation - as of v1.4.14 this issue has been fixed: https://github.com/akkadotnet/akka.net/issues/4421

Aaronontheweb
  • 8,224
  • 6
  • 32
  • 61