We found the answer for those questions. In summary: An ActorRef can be thought of as an address. Yes, we can send it over to other JVMs (so long as they are in the same cluster), and can be used to send messages to that Actor. However (and this is Very Very Important), this isn't a remote procedure call. It is absolutely illegal to make procedure calls to Actors, ever. Instead, you send them messages.
On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner < [email protected]> wrote: > In a more direct question, do agents instances need to be serializable? > > On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini < > [email protected]> wrote: > >> So we've hit a few problems with our original design, and we're >> discussing ideas for a possible alternative. >> >> When reading the documentation on akka actors and props ( >> http://doc.akka.io/docs/akka/current/scala/actors.html#crea >> ting-actors-with-props) one question came to mind regarding the >> following statement about the ActorRef type: >> >> "The ActorRef is also serializable and network-aware. This means that you >> can serialize it, send it over the wire and use it on a remote host and it >> will still be representing the same Actor on the original node, across the >> network." >> >> Do you guys happen to know if that means that the ActorRef is >> serializable and wherever it is used, will ALWAYS point to the original >> Actor, running on its original JVM, or, is it possible that it would be >> used to create another instance of the Actor, in another completely >> separate JVM? >> >> Cheers! >> Lucas >> >> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini < >> [email protected]> wrote: >> >>> Good catch. Seems that not much needs to be changed... I think simply >>> adding the Spring extension to the ActorSystem config should do the trick. >>> >>> While that GitHub example I mentioned does use Spring to set the >>> ActorSystem dependencies, I don't see that as being very useful for us >>> right now, since we'd only use Spring for Actor-specific dependencies. >>> >>> If using Spring for the ActorSystem is interesting to the project as a >>> whole, we could consider making some changes to make that work... >>> >>> I'll keep working on this as is for now. Let me know what you guys think >>> about the ActorSystem idea. >>> >>> Cheers, >>> Lucas >>> >>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes < >>> [email protected]> wrote: >>> >>>> I might be wrong, but in order to use Akka with Spring, dont we need to >>>> also change the way the ActorSystem is being instantiated on Fey? >>>> >>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini < >>>> [email protected]> wrote: >>>> >>>>> So after a while pondering and going back and forth between a few >>>>> possible implementations, I think we're on to something interesting. >>>>> >>>>> Let me try and give you guys an outline of the design we came up with: >>>>> >>>>> - Create an Akka extension that will load the Spring context, as >>>>> shown here -> https://github.com/typesafehub >>>>> /activator-akka-java-spring >>>>> - Implement an ActorProducer that will then instatiate the actors, >>>>> as shown here -> http://doc.akka.io/docs/akka/c >>>>> urrent/scala/actors.html#dependency-injection >>>>> >>>>> <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection> >>>>> - Modify "Orchestration.scala" to add an alternative >>>>> "CreateEnsemble" method which will use the Spring extension when >>>>> specified >>>>> - Modify "FeyCore.scala" by adding two possible fields to be >>>>> interpreted from the orchestration JSON. One to specify that the >>>>> performers >>>>> within that orchestration will be using Spring (so that we can call the >>>>> alternate method mentioned above); and another one specifying the path >>>>> for >>>>> the Spring context file >>>>> - Modify the JSON validator to reflect these changes. >>>>> >>>>> >>>>> This should keep the fey core generic, as we mentioned before, not >>>>> making using Spring mandatory. >>>>> >>>>> Let me know what you guys think! >>>>> >>>>> Cheers, >>>>> Lucas >>>>> >>>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <[email protected]> >>>>> wrote: >>>>> >>>>>> That sounds good. >>>>>> >>>>>> Thank you Lucas. >>>>>> >>>>>> Looking forward for the out coming results. >>>>>> >>>>>> This new feature will be a good fit for The Fey Engine. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Barbara Gomes >>>>>> +1 (650) 713-6092 <(650)%20713-6092> >>>>>> >>>>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini < >>>>>> [email protected]> wrote: >>>>>> >>>>>> I think using the Akka dependency injection system is a good starting >>>>>> point. It should be sufficient for our needs and shouldn't take too long >>>>>> to >>>>>> get it working. >>>>>> >>>>>> I'll try to get something up and running and report back. Once we get >>>>>> it going maybe we can discuss a feature proposal and eventually even >>>>>> bringing full spring integration to the fey core. >>>>>> >>>>>> Cheers! >>>>>> Lucas >>>>>> >>>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi there, >>>>>>> >>>>>>> I'm not very familiar with the Spring framework. >>>>>>> I spent sometime reading about it and how it would integrate into >>>>>>> Fey (Akka). >>>>>>> >>>>>>> Correct if I'm misunderstood: >>>>>>> >>>>>>> *@Rafael *is suggesting the complete integration of the Spring >>>>>>> framework into Fey. Which would be a bit more complex, since Fey would >>>>>>> have >>>>>>> to instantiate the Spring context and the Actor System would also have >>>>>>> to >>>>>>> be instantiated using the Spring context. Which would imply that all the >>>>>>> necessary configuration for the Spring framework would have to be >>>>>>> defined >>>>>>> upon Fey start-up (fey.conf file maybe). >>>>>>> >>>>>>> *@Lucas *is suggesting that we use the built-in dependency >>>>>>> injection that Akka offers. This approach sounds simpler than the Spring >>>>>>> integration, and would also keep the "Generic" idea of Fey, where the >>>>>>> developer should be able to use any framework he wants to. >>>>>>> >>>>>>> I personally think that it would be awesome if we could work on both >>>>>>> approaches. Here are my reasons: >>>>>>> >>>>>>> 1. Spring is a fairly complex framework, and having it >>>>>>> integrated on Fey core would be a huge plus and would also offer a >>>>>>> more >>>>>>> sophisticated dependency injection framework. >>>>>>> 2. Using the built-in Akka dependency injection would be cool as >>>>>>> well, since it seems way simpler to use and understand, and >>>>>>> developers that >>>>>>> are not familiar with the Spring framework (like me) would not have >>>>>>> a hard >>>>>>> time integrating it into the performers world. >>>>>>> >>>>>>> For both approaches, we would have to do some research and present >>>>>>> an Integration idea into Fey. >>>>>>> >>>>>>> Perhaps we could start working on the proposal for *@Lucas *suggestions >>>>>>> first? What do you guys think? >>>>>>> >>>>>>> *Just as a heads-up:* Unfortunately, Fey still have some class load >>>>>>> issues when the performer's dependencies are fairly complex. As an >>>>>>> example, >>>>>>> we wrote an Apache Ignite performer and we had to go to some hoops to >>>>>>> get >>>>>>> the Spring dependencies loaded in runtime, in fact, the final fix was to >>>>>>> manually add the dependency to the Fey Application when starting Fey, on >>>>>>> the run command (java -jar ...). Although it was a simple fix, it would >>>>>>> be >>>>>>> nice to not have to do it anymore. >>>>>>> >>>>>>> Looking forward to hear your thoughts. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I've been reading up on how Akka would handle dependency injection ( >>>>>>>> http://doc.akka.io/docs/akka/current/scala/actors.html#depe >>>>>>>> ndency-injection), and it seems that, as far as Akka is concerned, >>>>>>>> upon creating an Actor, we could pass a DependencyInjector and an >>>>>>>> ApplicationContext within the actor's Props. >>>>>>>> >>>>>>>> So now I'm imagining that bringing this functionality to Fey would >>>>>>>> be a simple matter of adding a few extra items (the DependencyInjector >>>>>>>> class and the ApplicationContext) to the json that defines an >>>>>>>> orchestration, and once the json is processed, verifying if those >>>>>>>> items are >>>>>>>> present, and adding those to the Props before calling akka to instance >>>>>>>> the >>>>>>>> actor. >>>>>>>> >>>>>>>> Still, I'm curious to see what you guys think about bringing this >>>>>>>> feature to the fey-engine. >>>>>>>> >>>>>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> We started developing our first agents (performers) using Fey, and >>>>>>>>> we found our first “problem”. There is no integration of Fey and >>>>>>>>> Spring. >>>>>>>>> Or at least, we did not understand how to integrate Fey with Spring. >>>>>>>>> >>>>>>>>> We want to instantiate our agents in Spring to enjoy all of its >>>>>>>>> benefits (e.g. dependency injection, object management, easy >>>>>>>>> transaction >>>>>>>>> configuration and so forth). Therefore, instead of telling Fey the >>>>>>>>> performer class to instantiate, we would have to tell Fey the source >>>>>>>>> as the >>>>>>>>> application context name and the bean name; so Fey can retrieve the >>>>>>>>> agent >>>>>>>>> (object) already instantiated by Spring. >>>>>>>>> >>>>>>>>> This would have consequences on the performer constructor; we >>>>>>>>> would need to add another hook to configure an agent in Fey such as a >>>>>>>>> post-constructor method that would be intended to do the same as the >>>>>>>>> constructor today. I mean, we maintain everything we have so far, and >>>>>>>>> we >>>>>>>>> add only a default constructor with no parameters and the >>>>>>>>> post-constructor >>>>>>>>> method that would be hooked in Fey’s performer life-cycle. >>>>>>>>> >>>>>>>>> Then, we would have to possibilities, first the one we already >>>>>>>>> have to instantiate an agent: >>>>>>>>> >>>>>>>>> "source": { >>>>>>>>> >>>>>>>>> "name": *"agentJarWithDependencies.jar"*, >>>>>>>>> >>>>>>>>> "classPath": *"org.awesomeCompany.agentOne"*, >>>>>>>>> >>>>>>>>> "parameters": { >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> And an alternative for agent objects managed by Spring: >>>>>>>>> >>>>>>>>> "source": { >>>>>>>>> >>>>>>>>> "name": *" agentJarWithDependencies.jar"*, >>>>>>>>> >>>>>>>>> "applicationContextName": >>>>>>>>> *"agentOneApplicationContext.xml"*, >>>>>>>>> >>>>>>>>> "performerBeanName": >>>>>>>>> *"agentOneApplicationContext.xml"* >>>>>>>>> >>>>>>>>> >>>>>>>>> This would require Fey to instantiate the Spring’s application >>>>>>>>> context, and then look the bean up there. The idea is that application >>>>>>>>> context file can be found in the classpath. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> What do you guys think about this? We can work to create this >>>>>>>>> integration after we discussed the changes that would be applied to >>>>>>>>> Fey. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Rafael Weingärtner >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Barbara Gomes >>>>>>> Computer Engineer >>>>>>> San Jose, CA >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Barbara Gomes >>>> Computer Engineer >>>> San Jose, CA >>>> >>> >>> >> > > > -- > Rafael Weingärtner > -- Rafael Weingärtner
