Hi Robert,
On Wed, Jun 8, 2016 at 12:05 AM, kraythe <kray...@gmail.com> wrote: > First of all, thanks for the reply! > > I am trying to do a fair bit of work to glue an actor system to a > non-actor system and that is the problem here. Sure, it would be nice if > the whole system was Akka. However, it isn't Akka at all and I am trying to > wedge Akka into the tech stack and prove ROI. It would be nice if I didn't > have to deal with legacy code but I do and there are 300k lines of it. Also > I cant say to my bosses "hey we need to stop all development and convert > the whole system to Akka now spending 6 months to convert legacy code to a > system I haven't proves will actually solve our problems and stopping other > development. I would get fired for that. And of course this isn't > greenfield development. Hopefully eventually the whole thing will be an > actor system but I have to work in small steps here. > > I will take your advice and work directly with the ActorSelection for now > because I don't like all that bad smell either. That is why I posted the > question. I appreciate your time in answering. If I can get this to work > then I can get it to take over the world. Now I just need a means to send > messages to millions of actors at once without iterating through them and > they are cluster sharded actors. One problem at a time to take over the > stack. :) > There is one more option for integrating, and it is a class named Inbox ( http://doc.akka.io/api/akka/2.4.7/index.html#akka.actor.Inbox). It allows you to send to, receive from and watch actors in a blocking way that might be necessary to integrate with synchronous legacy parts. The benefit compared to the ask pattern is that the internal ActorRef it has is stable and can be used in multi-reply scenarios, and it also allows to use watch. It is a little bit like test probes. As for isTerminated(), it is fully deprecated, it is weird that we have not removed it already given that 2 major versions have passed since. Please don't use it, it is not reliable and will go away. -Endre > > -- Robert > > On Tuesday, June 7, 2016 at 2:12:49 PM UTC-5, Justin du coeur wrote: >> >> Actually, again, this is very *un*common code -- all those statics are >> awfully surprising. Question: how much are you gluing Actors onto very >> non-Actor code? That's the only way I can interpret what you're doing >> here, and it's a bit unusual in my experience -- Akka tends to be pretty >> pervasive, so you don't generally see a *lot* of different types of Actors >> being accessed from the outside. More often, there's a *bit* of "Actor >> API" exposed to the non-Akka code, and the rest is all Actors talking to >> each other. (Also, it's moderately unusual to be doing so much with >> singleton Actors, especially with per-node singletons, so this pattern of >> storing an ActorRef in a static, which only makes sense for a per-node >> singleton, is downright rare in my experience.) >> >> As for the isTerminated() check, that's automatically a bad smell -- the >> isTerminated() method has been deprecated for a long, long time, and >> doesn't even exist in current versions of Akka. (I was downright puzzled >> by it -- I'd never heard of it before, until I went Googling around. Which >> version of Akka are you using?) I honestly don't know how that ever >> worked: an ActorRef is really just a fancy sort of address itself (more >> direct than ActorSelection, but still essentially an address), and has no a >> priori knowledge of whether the Actor is still running or not. From the >> comments I'm finding online, isTerminated() apparently never worked very >> well, and has been removed. >> >> Instead, you usually pro-actively find out that an Actor has terminated >> by putting a watcher (ActorContext.watch()) on it, so you get a >> notification when it dies, and would typically null out the ActorRef and >> maybe rebuild the Actor at that point. Honestly not sure how to do that >> watching from outside the Actor world, though -- I've never tried something >> like that, because like I said, it's not a common approach. In your case, >> I probably don't recommend trying. >> >> Regardless, yes, there are potential race conditions. That's pretty much >> always an assumption in the Akka world: you assume that there are races, >> and build the code to be tolerant of them as needed. If the Actor has >> died, then the messages will go to the dead letter box; in this case, the >> caller should time out and react appropriately. >> >> To your question of exceptions, no -- this doesn't look like it'll throw >> an Exception per se. Rather, the Exception (if there is one, usually a >> timeout) is wrapped up in that Try you get back from value(). You're >> checking the success case of that, but you should also handle the failure >> case -- *that* is your signal that the Actor is dead. (Or at least, that >> it failed to return in time.) >> >> Also, note that calling .value() is also automatically a bit of a bad >> smell -- that's a blocking call, and blocking always leaves you in danger >> of thread starvation and other such badness. It may well be necessary, if >> the surrounding code is all synchronous (common when adapting legacy >> systems), but keep in mind that the more you can make stuff reactive and >> Future-based, the less likely you are to get into trouble. >> >> Finally, I caution about over-optimizing around assumptions of >> efficiency. ActorSelection is a *bit* slower than ActorRef, yes, but my >> understanding is that you're trying to do everything locally within the >> node anyway, so my suspicion is that ActorSelection is still plenty fast. >> So I *suspect* you're complicating the code for what might be a very small >> optimization. From what I see here, I would *probably* just always use >> ActorSelection for this code unless profiling indicated otherwise... >> >> On Tue, Jun 7, 2016 at 11:48 AM, kraythe <kra...@gmail.com> wrote: >> >>> I am currently adding Akka to our existing system that currently does >>> distributed programming with Executors in Hazelcast. Obviously he executor >>> system is not scaling so I am currently working on how to convert it to an >>> actor system. The temptation I have is to do the code below for my scoring >>> manager but it feels so boilerplate and common that I feel I must be >>> missing something or doing something wrong. The scoring manager exists once >>> per node and I need to call it from a lot of places including other actors >>> so, upon reading the docs, I read that using ActorSelection to call all the >>> time is a performance issue so I thought caching the ref would be a good >>> idea. This is how I went about it. >>> >>> private static ActorRef scoringManagerRef = null; >>> >>> public static ActorRef start(final ActorSystem system) { >>> if (scoringManagerRef != null) throw new IllegalStateException("Already >>> started."); >>> scoringManagerRef = >>> system.actorOf(Props.create(LiveScoringManager.class)); >>> return scoringManagerRef; >>> } >>> >>> private static ActorSelection actorSelection(final ActorSystem system) { >>> return system.actorSelection(DEFAULT_PATH); >>> } >>> >>> public static ActorRef actorRef() { >>> if (scoringManagerRef == null || scoringManagerRef.isTerminated()) { >>> scoringManagerRef = null; >>> final Option<Try<ActorRef>> value = >>> actorSelection(Ruckus.getActorSystem()) >>> .resolveOne(new Timeout(1, TimeUnit.SECONDS)).value(); >>> if (value.isDefined()) scoringManagerRef = value.get().get(); >>> } >>> return scoringManagerRef; >>> } >>> >>> >>> The idea is that since there is only one per node, we can start it when >>> the ActorSystem goes up but if the actor system restarts the manager then >>> we want to refresh the ref. Of course there is always the chance that >>> milliseconds after we check for "isTerminated" the actor is actually >>> terminated. I am not so sure what would happen then, messages to DLQ? >>> Hopefully an exception would occur but which? >>> >>> Anyway I would need this pretty much everywhere on all of my Actors to >>> make calling them efficient so this seems to be something I must be doing >>> incorrectly. Any advice is appreciated. >>> >>> >>> -- >>> >>>>>>>>>> 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+...@googlegroups.com. >>> To post to this group, send email to akka...@googlegroups.com. >>> Visit this group at https://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 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. > -- Akka Team Typesafe - Reactive apps on the JVM Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> 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.
