Allan, your assumption is correct. Moreover you can use one dispatcher for
driving stream actors and another for driving your own actors allowing each
group to not step on the others toes.
On Thu, Nov 13, 2014 at 5:43 PM, Allan Brighton wrote:
> The stream could come from reading a file or could
The stream could come from reading a file or could be generated by the
application.
One idea would be to pass a Subscriber in an actor message that can be used
to read the data.
An alternative, as I think you are suggesting, would be to use a tcp socket
based on Akka IO (maybe an embedded HTTP
Where is the stream that you want to handle with akka-stream coming from?
Before materialization you can pass around Sources and Sinks in actor
messages. After materialization you can pass Publishers and Subscribers in
actor messages as well.
On Tue, Nov 11, 2014 at 8:15 PM, Allan Brighton wrote
Hi Martynas,
Thanks for your answer. What about the case of local actors in the same
ActorSystem?
It seems that it would be more flexible to pass a stream of bytes (or
ByteStrings) than to pass a File object in an actor message.
I have seen examples of reactive streams used to read/write file
Hi Allan,
currently akka-stream can only be materialized to actors on one
ActorSystem. Materialization to remote actors or cluster will come
eventually, but not soon.
However you can still use ActorPublisher and ActorSubscriber with remote
actors. Having said that, you need to keep in mind that s
Hi,
An actor needs to receive messages containing the binary contents of files
that can be around 35mb in size.
Rather than sending an actor message containing an Array[Byte] would it
make sense to send a message containing an Akka Stream
(for example, a Source[Byte])? Would this also work with
