Hi Jim, Simon. What you say is exactly what I did: I have a normal actor on a different dispatcher (but it could be any type of asynchronous code) that sends messages to an actor producer that acts as the Source of the stream.
+1 for adding more "external interaction" recipes on the documentation :) Cheers G On Friday, 20 February 2015 01:36:00 UTC, Jim Hazen wrote: > > I'd also be interested to know what the best practice patterns for > bridging internal/external stream boundaries are. In this case there isn't > yet a well understood pattern for external entities to dynamically feed > into a stream source. There is likewise no easy way for an external > library to tap a sink. How would one model the faucet in my house? It's a > well backpressured system, yet I can turn a knob and take(1.cup) off the > stream and process it in an external system. > > In your particular case, I'm thinking that using an ActorPublisher might > be the best way to go. Your custom ActorPublisher would act as a Stream > source, but also be known externally to the stream as a normal actor. It > would provide a generic out of band mechanism for other actors to send > messages to it. Newly arriving messages would become available for stream > consumption once demand was triggered. You can then subscribe this actor > to whatever external event streams you'd like. > -- >>>>>>>>>> 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.
