I'm aware that as of Akka 2.4.16, there is no "remote" implementation of Reactive Streams. The specification focuses on a stream running on a single JVM.
However, considering the use case to involve another JVM for some processing while maintaining back pressure. The idea is to have a main application that provides a user interface running a stream. For instance, this stream has a stage performing some heavy computations that should run on a different machine. I'm interested in ways to run streams in a distributed way - I came across some articles pointing out some ideas:
- Connecting streams via TCP using Akka HTTP (Stackoverflow)
- Simplifying it with Artery to a certain extent (Stackoverflow, Akka Blog)
- Integrating actors into a stream (Answer from Viktor Klang, Akka Docs)
What other alternatives are there? Are there any significant downsides to the above? Any special characteristics to consider?
Update: This question is not limited to a single use case. I'm generally interested in all possible ways to work with streams in a distributed environment. That means, e.g. it can involve only one stream that integrates actors with .mapAsync
or e.g. there could be two separate streams on two machines communicating via Akka HTTP. The only requirement is that back pressure has to be enforced among all components.
remote Actor
and Artery will take care of the messaging. – sarveshseri.mapAsync
for integrating remote actors in a stream has the same result: having a stream that processes something on a different machine. More generally asked: What are the ways to implement streams crossing JVM boundaries? – Toaditoad