You're welcome! I'm glad you managed to solve this puzzle :) W dniu środa, 9 marca 2016 15:00:06 UTC+1 użytkownik paweł kamiński napisał: > > beware of singletons in spring :] be lazy be prototype ;] > so updater ref for second connection was never created and then ask got > invalid ref or something like that because eventually messages were sent to > updater actor but from deadletter :) > > thanks for help :) > > On Wednesday, 9 March 2016 01:41:02 UTC+1, paweł kamiński wrote: >> >> thanks, for all help. >> >> it is running for ever as I am testing concepts of updating a remote >> client asynchronously, in real time Updater will get updates from other >> actors and yes I will add supervision strategies. >> Im running this app from unit tests that creates spring context and also >> http-serwer/actors along so maybe there is something funny going on. I ve >> never integrated akka with existing spring-based aps but this is just a >> proof of concept and I have almost identical app running both spring mvc >> with netty :) I ll dump logs to a file this way it should be easier to >> follow the flow. >> >> On Tuesday, 8 March 2016 23:33:38 UTC+1, Rafał Krzewski wrote: >>> >>> W dniu wtorek, 8 marca 2016 23:10:38 UTC+1 użytkownik paweł kamiński >>> napisał: >>>> >>>> but this is impossible to change concurrently as I log it and then pass >>>> to Pattern#ask. I just wonder why it is send from >>>> *akka://akka-system/deadLetters* and why *ReceiveTimeout* is not sent >>>> back to Updater... >>>> >>>> Oh, that's right! A message sent without specifying a sender (like when >>> you are invoking ActorRef.tell from outside an actor) originates from >>> deadLetters, but message from an ask should originate from /temp/$.... >>> Something really weird is going on here. >>> >>> Regarding the ReceiveTimeouts, The log entries are 25 minutes later, and >>> log format is different - I don't know what to make of that. Two different >>> program runs with configuration change in between? That would explain why >>> serial # of B1 actor is different. Otherwise I don't see why should it be >>> restarted, as the Updater actor appears to run "forever", unless you are >>> terminating it somehow from the outside (in the code not shown here). If >>> the actor crashed with an exception in receive, you'd notice that in the >>> log. Also you'd probably have to configure appropriate supervisionStrategy >>> in updater's actor parent to restart it. >>> >>> >>> >>>> the application I try to put together is a proof of concept and there >>>> is no use to use scala at this point. >>>> >>>> Well, it's a matter of what you are comfortable using. It would be much >>> shorter in Scala, and easier to read for some people, but harder for others >>> :) Neither am I suggesting that rewriting it in Scala would fix the problem >>> at hand. >>> >>> Cheers, >>> Rafał >>> >>
-- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
