[akka-user] Re: Akka-Streams: Pointers for implementing cache

2015-09-12 Thread Seamus Venasse
Here is a more appropriately named version of the FlexiRoute subclass: class OptionShape[A, B](_init: Init[(A, B)] = Name[(A, B)]("Option")) extends FanOutShape[(A, B)](_init) { val none = newOutlet[A]("optionNone") val some = newOutlet[B]("optionSome") protected override def construct(i:

[akka-user] Re: Akka-Streams: Pointers for implementing cache

2015-09-12 Thread Seamus Venasse
I was thinking of the solution using the wrong flow shapes. I want to check the cache first and then depending on its outcome to either continue with the happy path or to hit the website. I was able to accomplish this by looking at the FlexiRoute code in the "Custom Stream Processing" chapter

Re: [akka-user] How to live without ask()?

2015-09-12 Thread Richard Rodseth
See the thread(s) and Activator templates on per-request actors. With Spray I avoided ask completely by using per-request actors and messages with a replyTo property. Others use much more Future-centric approaches. Sent from my phone - will be brief > On Sep 12, 2015, at 5:15 PM, kraythe wrote

Re: [akka-user] How to live without ask()?

2015-09-12 Thread kraythe
Because they rely on waiting some amount of time for something to come back from elsewhere and that means that you tie up the actor while you are waiting. So our customer actor fires off futures for all his orders, then they fire off futures for all of the items. It is a truism that eventually

Re: [akka-user] How to live without ask()?

2015-09-12 Thread Justin du coeur
Hmm. Which problem are you concerned about with ask()? *Architecturally*, the ask pattern seems decently well-suited to the problem -- fire off a bunch of asks, maybe using Future.sequence() to collect the results together. Ask has some real issues when used *inside* of an Actor, but those can b

[akka-user] How to live without ask()?

2015-09-12 Thread kraythe
Greetings, I am completely sold on Akka and its abilities. I am even considering it for a game server (though Id have no idea how to get physics in there without reinventing the wheel, JNI maybe). What I am wondering about is a common paradigm in my applications. Basically it goes like this:

[akka-user] Re: Akka behaviour

2015-09-12 Thread Sergey Sopin
Workflow is following: -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >>

[akka-user] Akka behaviour

2015-09-12 Thread Sergey Sopin
Hi all, I have problems with Akka in case of errors, namely: Ask time out. I suppose that the system should stop processing and restart itself when error happens. I have supervisor actor with following supervision strategy: private static SupervisorStrategy strategy = new OneForOneStra

[akka-user] Re: How can a PersistentFSM handle a restart as an Event

2015-09-12 Thread Leonid Bakaleynik
Hi R Welling, onRecoveryCompleted is meant to be a hook for handling side effects - operations not affecting the domain state, that need to be executed following the recovery, like sending a message to another actor, or logging, or maybe initializing something inside the actor. This function wa