On 20/02/2017 21:27, Rafał Krzewski wrote:
As far as I know, the only situation when blocking in actor code is justifiable is interacting with legacy code that just blocks the calling thread and offers no way around it, like JDBC does. Of course one should use a dedicated dispatcher then, to avoid starving regular actors of resources.
I have a related design question. I've written a Persistence Journal implementation that stores JSON in flat files, one file per persistent actor. Each journal file is managed by a dedicated actor which performs the actual file IO.
The AsyncWriteJournal actor's asyncWriteMessages method returns a Future[immutable.Seq[Try[Unit]]] where the Future denotes the success/failure of the IO operations. I've implemented that by performing the JSON serialization of each message in the AsyncWriteJournal actor and then passing the resulting JSON to the per-file IO actor, building up a list of the futures for each write operation. I then use Future.sequence to transform the list of individual IO futures into a single future to return from asyncWriteMessages. All the IO actors share a dedicated dispatcher.
Is that the best approach? I could possibly avoid the need for separate IO actors and issue the IOs from the asyncWriteMessages method - but then I assume it would block.
What isn't clear to me is what happens to the Future returned by AsyncWriteJournal.asyncWriteMessages, is it waited for by the AsyncWriteJournal implementation or is it the PersistentActor that issues the original persistence operation that waits? As far as I can tell there's only one AsyncWriteJournal actor per actor system so I'm assuming that avoiding blocking in it is important, particularly if the Future that your AsyncWriteJournal implementation returns from asyncWriteMessages is for a blocking operation.
I did also wonder about delegating the JSON serialization to a separate actor rather than doing it in the AsyncWriteJournal actor (I'm using spray for the serialization) and then using pipeTo to pass the JSON to the IO actor , but the performance I'm getting from the Persistence TCK benchmark is more than adequate for my needs - ~62k records/second, so I didn't bother, plus I noticed that other existing Persistent Journal implementations do serialization in the same way.
Thanks, -- Alan Burlison -- --
--- You received this message because you are subscribed to the Google Groups "Akka User List" group.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
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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
