Hi Rafael, Glad you guys figured that out. As I said in one of the previous thread, Fey does not support remote actors, so I'm not sure how are you guys able to instanciate an actor in a different JVM using fey.
Do you mind explain it ? Barbara Gomes +1 (650) 713-6092 > On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner > <[email protected]> wrote: > > 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#creating-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/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 >>>>>>> >>>>>>>> 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: >>>>>>>>> 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. >>>>>>>>> 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#dependency-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
