I assumed the commented code was in the spirit of "oh, and the commented stuff didn't work out for me, plz help." :-)
-- Konrad Malawski geecon.org / java.pl / krakowscala.pl / gdgkrakow.pl From: √iktor Ҡlang [email protected] Reply: [email protected] [email protected] Date: 21 March 2014 at 16:29:12 To: Akka User List [email protected] Cc: glidester [email protected] Subject: Re: [akka-user] Chaining actor ask calls How is that possible, that code was commented out? On Fri, Mar 21, 2014 at 5:22 PM, glidester <[email protected]> wrote: Yes that was it! Thank you so much Konrad. On Friday, March 21, 2014 4:14:28 PM UTC, Konrad Malawski wrote: The reason might be that you're calling sender() inside the Future's map. The sender() call is only valid within the actor itself, and this construction (f map { sender ! ... }) might run in annother thread - making the sender not what you might expect it to be - thus, the reply goes to "someone" and not the intended sender (well, deadLetters probably). it should "work" in { // given val he = system.actorOf(Props(new Actor { import context.dispatcher implicit val timeout = Timeout(2.seconds) def receive = { case x => val respondTo = sender() // "freeze" the sender value Future { Thread.sleep(500) // wrong // sender() ! x + "!" // the test will timeout, because reply goes to deadLetters! // good respondTo ! x + "!" // good; the right actor gets the response } } })) // when he ! "hi" // then expectMsg("hi!") } There's a nice post from Helena Edelson explaining problems explaining it a bit more: http://helenaedelson.com/?p=879 and the sender()'s scala docs mention this: * WARNING: Only valid within the Actor itself, so do not close over it and * publish it to other threads! */ final def sender(): ActorRef = context.sender() There is some ideas to make this error "not as easy to make", with Scala's "spores", but that's not here yet… I hope this helps, cheers! -- Konrad Malawski geecon.org / java.pl / krakowscala.pl / gdgkrakow.pl From: glidester [email protected] Reply: [email protected] [email protected] Date: 21 March 2014 at 15:35:27 To: [email protected] [email protected] Cc: glidester [email protected] Subject: Re: [akka-user] Chaining actor ask calls Ok, so it seems people prefer tell to ask. The only reason I'm using ask is that the example I'm working from http://doc.akka.io/docs/akka/snapshot/scala/testing.html#Testing_the_Actor's_Behavior uses ask. I'm writing some unit tests to test my Actor 'a' calling Actor 'b'. My Actor 'b' is outside my control (3rd party module) so I have to ask it. I've modified my test code to 'tell' Actor 'a' but now I get Timeout exceptions. I think it might have something to do with unit tests being single threaded but I'm unsure. Here are the snippets of my code: case class ReadEntry(licKey: String) class LicenceBlackList extends Actor with ActorLogging with DynamoModelObjects { val dynamoActorRef = Dynamo(DynamoConfig(System.getProperty("amazon.accessKey"), System.getProperty("amazon.secret"), tablePrefix = "test_blacklist_", endpointUrl = System.getProperty("dynamo.url", "https://dynamodb.eu-west-1.amazonaws.com";)), connectionCount = 3) def receive = { case ReadEntry(licKey) => { log.info(s"ReadEntry $licKey") val result: Option[BlacklistEntry] = Read(licKey).blockingExecute sender ! result /*val dd: Future[Option[BlackListEntry]] = (Read(licKey) executeOn dynamoActorRef) dd.map { result => sender ! result //I get:- java.lang.AssertionError: assertion failed: timeout (3 seconds) during expectMsg while waiting for Some(BlacklistEntryImpl(TEST_KEY_1,1000,First Test Entry)) }*/ } } } class LicenceBlackListSpec(_system: ActorSystem) extends TestKit(_system) with ImplicitSender with ShouldMatchers with FlatSpec with BeforeAndAfterAll { def this() = this( ActorSystem("LicenceBlackListSpec") ) override def afterAll: Unit = { system.shutdown() system.awaitTermination(10.seconds) } implicit val timeout = Timeout(10 seconds) val blacklistRef = TestActorRef(Props[LicenceBlackList]) "An LicenceBlackList Actor" should "be able to retrieve a blacklisted key" in { val licenceKey="TEST_KEY_1" blacklistRef ! ReadEntry( licenceKey ) val expected: BlacklistEntry = BlacklistEntryImpl(licenceKey, 1000 ,"First Test Entry") expectMsg( Some(expected) ) } } When I run my test class I get: [INFO] [03/21/2014 15:32:35.917] [pool-58-thread-2] [akka://LicenceBlackListSpec/user/$$a] ReadEntry TEST_KEY_1 [ERROR] [03/21/2014 15:32:45.933] [pool-58-thread-2] [akka://LicenceBlackListSpec/user/$$a] Futures timed out after [10 seconds] java.util.concurrent.TimeoutException: Futures timed out after [10 seconds] What am I doing wrong in my tests? Thanks On Friday, March 21, 2014 12:08:19 PM UTC, Konrad Malawski wrote: Hello there, In general always perfer tell (!) instead of ask (?), unless you have a compelling reason not to. It has less overhead, and I also find things nicer to model using plain actor tell's instead of ask's - which mix up styles a little bit (actors in general "fire and forget"). But let's also look at your example, because I think you may have mixed up what Future[_] gets completed when. The futures don't automatically get composed, but by chanining of reactions to a futures completion, actors can "cascade" completing their corresponding futures. In the bellow example we use ask twice. The a actor completes the fa future, but only once the fb future completes successfuly. Completing an "ask created Future", happens when an actor replies to the message sent by ask - so in the end => b completes the fb future, which then triggers the map in a, which completes the fa future. import akka.pattern.ask val b = context.system.actorOf(Props(new Actor { def receive = { case s => sender() ! s // this response completes the `fb` future } })) val a = context.system.actorOf(Props(new Actor { def receive = { case s => val replyTo = sender() val fb = b ? (s + "!") fb map { bResponse => // this runs when the b actor replies - thus, completing the `fb` future replyTo ! bResponse // this completes the `fa` future } } })) val fa: Future[Any] = a ? "wat" // this future will be completed by the `a` actor replying to the "wat" message -- Konrad Malawski geecon.org / java.pl / krakowscala.pl / gdgkrakow.pl From: glidester [email protected] Reply: [email protected] [email protected] Date: 21 March 2014 at 11:49:05 To: [email protected] [email protected] Subject: [akka-user] Chaining actor ask calls Hi, I'm in the process of learning Akka and I wondered if anyone could clarify something for me. If I have 2 actors. I 'ask' Actor A which in turn 'asks' Actor B. This means I get returned a Future from ActorB wrapped in a Future from Actor A (correct?) Is this good practice? Should I be using "tell" instead to avoid the nested Futures? Any pointers gratefully received! G -- >>>>>>>>>> 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. -- >>>>>>>>>> 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. -- >>>>>>>>>> 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. -- Cheers, √ ——————— Viktor Klang Chief Architect - Typesafe Twitter: @viktorklang -- >>>>>>>>>> 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. -- >>>>>>>>>> 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.
