Connecting multiple synchronous "FRP worlds"

(Oscar Broman) #1

I apologize for the title. I found it hard to describe this problem in a few words.

I currently have a system build upon actors, each containing a FRP world (similar to scala.rx).
In each actor, some variables can be modified by sending messages to it. Conversely, some variables are observed and messages will be sent when they are triggered (then triggering changes in other actors).

By doing this, I can connect these synchronous actors with each other. However, this introduces the problem which I’m trying to solve: back-pressure.

To solve this, I thought I’d take a step back and rebuild this with akka-stream.

Should I put each FRP world, which now exists in actors, into a GraphStage? Or perhaps I should use streams to communicate between actors?

The only way I’ve came across communicating between actors seems to be one where I must send an ack for each message - that impacts performance heavily.

Ideas, suggestions?

(Patrik Nordwall) #2

You could do that. It would be very good performance, but it’s local only.

That would also work, see options in docs.

You might also be interested in Stream refs, if you need streams over the network.

That is not the only way. You can use the work pulling pattern by requesting more than one item, or acknowledging more than one item. I have created an example of that.

(Oscar Broman) #3

Thanks for the response!

I looked into your suggestions and it seems most suitable for me to keep using actors. However, I still wish to use akka-stream for communicating between FRP worlds.

The example you sent does not use akka-stream. Would it be easy (and make sense) to combine the two?

Some input/output vars are intended to be consumed/produced in other places (e.g. synchronizing state over WebSocket). Other inputs/outputs are intended to be rate-limited, not necessarily by the producer.

So I think my question boils down to: how I can make actors with (conceptually) multiple streams between each other, each stream having customizable throttling/rate limiting?

(Patrik Nordwall) #4

See for how to integrate actors and streams. Ask is my first choice when calling out to actors from a stream, and Source.queue or Source.actorRefWithAck when emitting into a stream.

This is also a good blog post:

(Oscar Broman) #5

I looked at both those prior to writing the first post. In most cases, sending an ack for each message is superfluous.

Perhaps your example could be used in combination with the methods outlined in stream-integrations, or would that require adhering to all the nitty-gritty in the reactive-streams specification?

Some of the different FRP worlds will be on other machines, and then it would become even more important to have a request window rather than sending acks for individual messages.