Hmm. Just a few comments. First, if *possible*, I'd put EndPont.BuildNewOne() inside the processor Actor, to encapsulate it. I don't know if that's feasible in your environment, but it seems like it fits the usual Actor way of thinking about things.
On Sun, Nov 6, 2016 at 2:34 AM, Dmitri Krylov <[email protected]> wrote: > However, this literal translation looks very scary: naturally, the event > producer knows nothing about my life with Akka and Actors, and actually I > need to bridge it somehow to my world. But I don’t understand how to do it. > I could try to save self()(or some other event processor’s ActorRef) in the > listener object and send the event to this ActorRef(replacing handleEvent > call by "eventProcessor ! EventArrival(event)", but... does it make any > sense outside of our execution context? > Yeah, that seems like the way I'd handle it. Keep in mind, an executionContext is *not* a thread; these sorts of callbacks on outside threads are quite common (usually expressed as Futures on the Scala side of the world), and responding to them with a message send is usually the way to deal with it. I agree that saving self and routing back to it (or creating a child Actor and routing to that) is likely the most straightforward approach. (With a raw callback like this, anyway. In the Scala world I'd rewrite that as a Future and use akka.pattern.pipeTo on it, but I don't know how easy that is from Java.) > But now I'm inside my EndpointProcessor Actor. Well, I could do the same > using context.system. However, this looks ugly and I prefer > EventProcessorActor to be a child of EndpointProcessor — but then, again, > I’m not sure whether it is OK to store ActorRef inside non-actor > EventListener object — and probably it is not, because of third-party > calling thread for onEvent(). > I don't actually see an obvious problem with that. ActorRefs are just objects, and routinely get invoked from miscellaneous threads. That's one of the strengths of Akka: you *don't* usually have to worry much about which thread you're on. > On the other hand, the task(subscribe on the fly to third-party events > outside of Akka) looks pretty standard, and I’m probably just inventing a > wheel due to my own ignorance. I’ve tried to search in Akka docs, but > couldn't find something relevant, or maybe just missed it. Should I check > Streams more thoroughly? > They're worthwhile and powerful, and *might* be useful if thinking about this problem as a stream of events makes sense, but it's not obviously The Right Way to handle this case. I actually think you're heading in a reasonable direction, so I recommend trying it out and not over-thinking it too much at the beginning... -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
